Вход | Регистрация
    1  2  3  4  5  6  7  8  9  10   
Информационные технологии :: 1С:Предприятие 8 общая

Зачем нужны регистры, если все можно взять из документов?

Ø [Волшебник, 22.04.21 - 09:56]
Зачем нужны регистры, если все можно взять из документов?
Я
   brainguard
 
14.04.21 - 13:39
Есть ли какие-то соображения, кроме быстродействия?
   Провинциальный 1сник
 
701 - 21.04.21 - 07:57
(696) 30 минут для закрытия месяца - это много. Любой сколь нибудь длительный алгоритм с интерактивным запуском должен выполняться не дольше, чем выпить заварить и выпить чашку кофе. Если дольше, то надо перерабывать структуру данных и алгоритм, разбивая его на автономные участки, выполняемые независимо. ИМХО.
   Mikeware
 
702 - 21.04.21 - 07:57
(699) пре-поддает, и после-поддает
   Mikeware
 
703 - 21.04.21 - 07:59
(701) "... интерактивным..."!
а должно ли закрытие быть интерактивным?
ну и не все алгоритмы параллелятся.
   Bigbro
 
704 - 21.04.21 - 08:01
(700) удобство круглого колеса - оно только при движении по ровной поверхности. но существуют поверхности по которым например удобнее ездить на транспорте с квадратными колесами.
http://www.bikeshot.ru/videotube/velosiped-s-kvadratnymi-kolesami.html
   Провинциальный 1сник
 
705 - 21.04.21 - 08:06
(703) К сожалению, иногда (я бы даже сказал в большинстве случаев) закрытие месяца - это не итог всех работ, а по сути начало исправления допущенных в учете в течение месяца ошибок. Поэтому без интерактивности никуда не деться. К сожалению, в ЕРП и обрезках закрытие месяца крайне тяжелое, даже на относительно небольшом объеме данных.
   Mikeware
 
706 - 21.04.21 - 08:15
(704) угу. только поверхность для квадратных колес - искусственная. (для "фигур постоянной ширины" много разных приколов) Примерно так же и в учете - можно, допустим, упростить "учет по документам", если в каждом документе количество строк будет соответствовать количеству номенклатуры предприятия :-) Ну, или еще какой изврат.
(705) ну, мы справляемся  "предварительным закрытием", исправлением ошибок, и "окончательным". редко - в три этапа. Интерактивность, конечно, была бы приятным бонусом - но, строго говоря, не обязательна.
оффтоп: это напоминает мне подход к программированию "тогда" и "сейчас". тогда, при неинтерактивном процессе, обдумывался алгоритм, прикидывались модели данных,  и лишь потом "неинтерактивно" машинокодировалось, исполнялось. а сейчас обезъяна садится за клавиатуру с монитором, и начинает интерактивно хренячить, почти не думая, допуская и исправляя ошибки... вроде и ошибки благодаря интерактивности быстрее выявляются и исправляются... но при неинтерактивном подходе они бы и не возникли... получается "крысиные бега" с точно таким же результатом.
   Irbis
 
707 - 21.04.21 - 08:16
(704) Для подобного придумали гусеницы, опять же используя качение круглого по ровному.
   Irbis
 
708 - 21.04.21 - 08:18
>> обезъяна садится за клавиатуру с монитором, и начинает интерактивно хренячить, почти не думая, допуская и исправляя ошибки.
Люди не менябтся, если можно что-то не делать или делать как легче, то так оно и произойдёт.
   Провинциальный 1сник
 
709 - 21.04.21 - 08:25
(706) "вроде и ошибки благодаря интерактивности быстрее выявляются и исправляются... но при неинтерактивном подходе они бы и не возникли"
Чтобы ошибки не возникали, нужно глубокое понимание исполнителями сути того, что они делают. А в случае современных типовых конфигураций эта суть максимально от них скрыта разработчиками.
   Mikeware
 
710 - 21.04.21 - 08:37
(709)  "суть максимально от них скрыта разработчиками." - угу. но зато разработчиками облегчен ввод данных, и создание этой самой "сути".
ну и "понять суть сделанного" при желании исполнитель может. вот механизм - иногда не может.
Да и вопрос - надо ли понимать суть, и до какой глубины (до какого уровня) - остается открытым.
   DimVad
 
711 - 21.04.21 - 08:50
Ну возьмём простейшую задачку.

Есть справочник контрагентов, есть по ним начисления (пусть только разные услуги), есть оплата (пусть только безнал).
Попытаемся вести учёт вообще без регистров - т.е. не сохраняя сальдо.
Конфигурация - полностью самописка, что хотим то и воротим.

Итак, мы каждый раз берём все начисления и все оплаты за всю историю взаиморасчётов. Пока в теории всё нормально. Но смотрим :

С 1 января 2021 года было принято решение при наличии задолженности по услуге №1 и переплате по услуге №2 производить зачёт. В программу были внесены соответствующие изменения. Оборотки за 3 месяца начальством были "приняты" но :

с 1 апреля 2021 решение было отменено и взаиморасчёты стали вестись отдельно в разрезе каждой услуги. В программу были внесены соответствующие изменения.
При наличии бухгалтерских регистров - никаких проблем. Старые периоды закрыты, остатки - в регистрах.

Без регистров - нужно писать программу, которая постоянно анализирует период и считает "в соответствии с историей".

Таких событий за 10 лет было "over дофига". Наша программа просто гарантированно что-то где-то не учитывает и главбух со страшным криком "млять, у меня сальдо с прошлого года поползло !!!" бежит убивать программиста :-)

p.s. А там ещё менялись всякие НДС-ы, и нужно вычислять "НДС начисленный" и т.д. ПО ПЕРИОДАМ :-)
А если чуть сложнее - там ещё зарплата и дума оперативно придумывала всякие законы...

Вывод - такое мог придумать только чистый теоретик. Когда я писал нетленки на клиппере "регистры" были.
   brainguard
 
712 - 21.04.21 - 08:52
(696) Доказать - это значит провести сравнительный анализ, что будет без регистра и что будет с регистром. И указать конкретные места, где удобство проявляется
   Провинциальный 1сник
 
713 - 21.04.21 - 09:01
(710) В любом случае. Современные решения для учета от 1с подменяют _знание_ некой "практической магией". Буквально: какие жертвы принести и какие заклинания произносить, стоя лицом к востоку, чтобы совершилось чудо в виде правильного результата. В некоторых случаях такой подход работает, но чаще всего - нет. Потому что чем хуже операторы разбираются в теме, тем более высокая квалификация требуется от постановщика учета. В условиях ларька и малого бизнеса как правило постановщик учета - это или франч, которому лишь бы побольше часов закрыть, или фикси, который одновременно и картриджи заправляет и ему не до вникания в тонкости учета..
   brainguard
 
714 - 21.04.21 - 09:10
(697) Потому что я создал эту ветку перед публикацией статьи. Для того, чтобы проверить - не прошло ли мимо моего внимания что-то простое и очевидное. Быстродействие мимо моего внимания не прошло. Было бы странно, если бы прошло, как вы понимаете. Поэтому я и просил привести аргументы за регистры помимо быстродействия. Я получил то, что хотел. Спасибо мисте! Хотя статья уже опубликована, я все равно буду рад, если в оставшихся до 1000 постах кто-то расскажет мне про регистры что-то, что я не знал
   Mikeware
 
715 - 21.04.21 - 09:12
"Современные решения для учета от 1с подменяют _знание_ некой "практической магией"" - можно сократить до "Современные решения подменяют _знание_ некой "практической магией""
всего 35 лет назад мы сами паяли компьютеры, писали компиляторы ,и на самопаяных компьютерах самописными компиляторами или интерпретаторами создавали свои прикладные программы...
сейчас это непродуктивно, поэтому для программиста-прикладника все эти компьютеры-процессоры и даже компиляторы-интерпретаторы сместились в раздел "практической магии"
   brainguard
 
716 - 21.04.21 - 09:12
(710) Вот, кстати, спасибо вам. Подводите обсуждение к самой сути. Есть разработчики конфигураций и есть широко понимаемые пользователи. Широко - это значит включаем туда разработчиков низового уровня. Теперь внимание - вопрос! Кому должно быть удобно? Разработчикам конфигураций или пользователям?
   Иванович Михаил
 
717 - 21.04.21 - 09:14
(714) Уже все рассказали, но кто-то не хочет слышать. Бедные люди, которым вы читаете ваш "курс", какая каша у них в голве.
   brainguard
 
718 - 21.04.21 - 09:15
(700) В документе соединены деньги и количества товаров. Я напишу две функции. Одна вычисляет взаиморасчеты. Другая - остатки на складе. И тоже "разграничу". И, заметьте, гораздо более "логически"
   brainguard
 
719 - 21.04.21 - 09:17
(717) От вас я пока услышал, что колесо круглое
   fisher
 
720 - 21.04.21 - 09:18
Прочитал статью ТС на хабре.
Если выбросить всю воду, автор говорит - ну, время-то прошло, прогресс ушел вперед, пора уже сделать такую систему где разработчик 1С не будет сам проектировать регистры и сам мучиться со всеми связанными с этим сайд-эффектами, а "пускай оно как-нибудь все само". Кэширует там как-то мол исходя из запросов. Ну, ок. Догадался скайнет, допустим, до правильного кэширования. Получился объем персистент-кэша сопоставимым с объемом регистра (или в разы его превышая). Как его скайнету обновлять при изменениях задним числом? Или проблемы скайнетов шерифа не волнуют?
   Иванович Михаил
 
721 - 21.04.21 - 09:19
(718) Какая глупость.
   brainguard
 
722 - 21.04.21 - 09:19
(711) Так в и модулях проведения документов тоже будут стоять условия на дату. И там тоже будет вся эта сложность. Вы можете сами догадаться - чем плохо, если этой сложности там не будет. Или спросить здесь у коллег. Функция тем и хороша, что не позволит сделать плохо
   DimVad
 
723 - 21.04.21 - 09:24
(722) Зачем мне в модулях держать все эти условия ? Я не собираюсь перепроводить эти документы за 10 лет.
Документ сделал движения 2 февраля 2004 года. Начисления - записал в регистр.

С той даты способ расчета начислений изменился десять тысяч пятьсот раз.

Но я не храню эти алгоритмы в документе. Они мне нафиг не нужны. Есть запись в регистре от 2 февраля 2004 года - И ЭТО НАВСЕГДА.
   Mikeware
 
724 - 21.04.21 - 09:25
(716) должно быть удобно всем. баланс удобств пользователя и разработчика - это вопрос цены.
   Garykom
 
725 - 21.04.21 - 09:27
(716) Судя по тексту вопроса кто то не понял регистры, они для него слишком сложные и просит упростить ))
   brainguard
 
726 - 21.04.21 - 09:28
(724) Золотое слово - цена. Разработчиков конфигураций сотни, а пользователей сотни тысяч. Чье удобство даст больший экономический эффект?
   Garykom
 
727 - 21.04.21 - 09:29
Никто не мешает не пользоваться всеми возможностями платформы 1С при разработке решений-конфигураций
Не нравится РН и РС не используйте
Можно только на справочниках все делать
   Garykom
 
728 - 21.04.21 - 09:29
(726) Пользователи конфигурации не пишут и даже про регистры в 1С часто не знают.
Так что вопрос удобства разработчиков
   Mikeware
 
729 - 21.04.21 - 09:29
(718) не только деньги и количества товаров, но еще и резервы, заказы, аналитики....
да, это можно перенести на уровень функции получения итогов.  в итоге мы все равно упремся в рычаг "время-объем". но с точки зрения разработки хранение предварительно расчитаных данных по документу удобнее. и с точки зрения пользователя хранение предварительно расчитаных данных по документу удобнее тоже.
   Garykom
 
730 - 21.04.21 - 09:30
(728)+ Кому не нравится может взять ексель (сколько там он сча стоит?) и писать свои уникальные алгоритмы вручную ))
Не используя промежуточные таблицы между первичкой и итоговыми отчетами
 
 
   Mikeware
 
731 - 21.04.21 - 09:31
(726) экономический эффект - кому?
сотни тысяч пользователей создают "экономический эффект" Нуралиеву...
   brainguard
 
732 - 21.04.21 - 09:33
(728) Вы невнимательно читаете вопрос
   fisher
 
733 - 21.04.21 - 09:34
(726) То есть ты предлагаешь смотреть только на доход, забыв про себестоимость? Ну-ну.
   dvpk
 
734 - 21.04.21 - 09:35
(726) В чем удобство пользователя когда он полчаса ждёт формирования отчета?
   brainguard
 
735 - 21.04.21 - 09:35
(731) В первую очередь они создают эффект себе. Если бы его не было, не было бы и эффекта у Нуралиева
   brainguard
 
736 - 21.04.21 - 09:36
(734) Прочтите историю вопроса
   dvpk
 
737 - 21.04.21 - 09:37
(736) Я прочел. А вы на мой ответите?
   Иванович Михаил
 
738 - 21.04.21 - 09:38
(736) А как вы планируете получать остатки на каждый день например, за некоторый период?
   dvpk
 
739 - 21.04.21 - 09:40
(738) Он напишет суперэффективную и удобную функцию.
   Mikeware
 
740 - 21.04.21 - 09:40
(735) совсем не обязательно. все эти "переходы на восьмерку" ,"сертификации", ИТСы - они больше не для пользоватетелей, они больше для разрабов.
   PLUT
 
741 - 21.04.21 - 09:41
учет, старый новый

https://habr.com/ru/post/552668/

"Настоящее быстродействие мы получим тогда, когда пользователь, запросив данные по себестоимости, получит их моментально, потому что система знает, когда эти данные потребуются этому пользователю и вычисляет их накануне ночью"

в удивительное время живем, хотя в будущее могут смотреть не только лишь все. мало кто может это сделать
   Mikeware
 
742 - 21.04.21 - 09:41
(738) а в чем, собственно, проблема?
данные у вас есть, алгоритм получения остатков есть....
   Mikeware
 
743 - 21.04.21 - 09:44
(741) да... это еще в 91 году препод по БД нам объяснял: "самая эффективная стратегия кэширования - получение данных в кэш непосредственно перед тем, как данные запросит пользователь" :-)))
"к сожалению, как реализовать подобную стратегию - пока не придумали"©
   fisher
 
744 - 21.04.21 - 09:51
(715) Так и есть. С усложнением области все меньше остается людей, осознающих проблемы в комплексе. Все больше людей оперируют узкими слоями знаний, все больше областей знаний оставляя белыми пятнами. В итоге когда берутся рассуждать о проблемах, выходящих за области их узкой компетенции, то количество "магии" которым они при этом берутся оперировать - огромно. При этом я даже не про абсолютных профанов говорю. Человек даже может иметь профильное образование, но при этом все равно очень плохо представлять себе границы применимости различных технологий. А для сложных решений речь ведь даже не про границы применимости. А про тонкий инженерный баланс удовлетворения противоречивых требований. Чтобы его чувствовать - нужно иметь предельно четкую карту знаний.
Я это все к чему? Количество чуши в околоайтишных статьях будет только расти :)
   Garykom
 
745 - 21.04.21 - 10:06
(743) OLAP придумали давно
Это когда в кэш (надо дофига места) загоняют всевозможные данные которые могут понадобится юзеру
   brainguard
 
746 - 21.04.21 - 10:15
(737) Вопросы быстродействия мы не обсуждаем. Пользователь не будет ждать полчаса. Давайте поставим на этом точку
   Mikeware
 
747 - 21.04.21 - 10:15
(744) а причем тут "околоайтишность"? растут все сферы, растут объемы познанного. представьте простого _хорошего_ выпускника средней школы в качестве советника, скажем, Пауля Хартека в 1938-м.. история могда пойти сильно по-другому...
опять же,
"В средней школе я еще делил свои привязанности между историей и точными науками, а при поступлении в колледж я с головой окунулся в науку.

В колледже я узнал, что среди главных научных дисциплин мне нужно выбрать «главнейшую» для меня самого. Я заигрывал с зоологией, а потом, на втором курсе, окончательно остановился на химии. Это означало, что мне всего-навсего надо было слушать по одному курсу химии в каждом семестре. Но, поступив в аспирантуру, я понял, что химия химии рознь; для подготовки диссертации надо было выбрать из всех разделов химии один.

Постепенно справившись с некоторой присущей мне инертностью, я наконец занялся биохимическими исследованиями. За работу в этой области я получил звание доктора философии и без промедления приступил к преподаванию биохимии в медицинском институте.

Но даже эта область знаний оказалась слишком обширной… От беспорядочного чтения — к научной литературе, затем к науке, к химии, к биохимии, и это было еще не все. Занимаясь научной работой, я должен был ограничиться участком в одном из уголков сада — биохимии — и начал трудиться над нуклеиновыми кислотами…"
© Азимов, 1965 год
   Иванович Михаил
 
748 - 21.04.21 - 10:17
(746) Конечно не будет, с вашей технологией он два дня ждать будет.
   Mikeware
 
749 - 21.04.21 - 10:17
(746) вопросы быстродействия непосредственно связаны с объемом данных и косвенно со скоростью проектирования и отладки.
   Mikeware
 
750 - 21.04.21 - 10:19
(745) даже сам термин OLAP появился подже. Кодд его ввел в 1993 году.
Ну и в ОЛАПе - не кэш, а предварительно расчитанные итоги. вы ж итоги регистров кэшэм не считаете? или таки считаете?
   Bigbro
 
751 - 21.04.21 - 10:21
(746) конечно не будет. он через 20 минут наберет начальника и скажет "тут ваш новый программист наворотил хрени, и то что раньше работало за 1 секунду теперь 20 минут формируется, что делать будем?" начальник транслирует этот же вопрос высшему руководству. которое транслирует вниз директиву "нахрен с пляжа".
и пойдет данный уникум писать очередные унылые посты про то что быстродействие не важно.
   Mikeware
 
752 - 21.04.21 - 10:22
(751) теоретически, можно довести быстродействие до нормального. вопрос то - традиционный китайский....
   Garykom
 
753 - 21.04.21 - 10:23
(750) кэш это все хранимое на диске/памяти и служащее для цели ускорения
   Mikeware
 
754 - 21.04.21 - 10:23
(753) лечиться вам надобно, барин...©
   Garykom
 
755 - 21.04.21 - 10:25
(754) Да я в курсе что этот термин предполагает что размер кэша меньше размера полных данных
OLAP это просто доведенный до абсурда кэш, превысивший данные
   dvpk
 
756 - 21.04.21 - 10:28
(746) А как вы этого добьетесь без регистров?
   Garykom
 
757 - 21.04.21 - 10:29
(755)+ Когда скорость выполнения запросов к СУБД превысила некоторый порог то смысл OLAP начал пропадать

Так и с идеей ТС, при превышении некоторого порога быстродействия СУБД смысл в регистрах (как промежуточных сводных данных) пропадет
   Волшебник
 
758 - 21.04.21 - 10:29
(750) итоги регистра — это кэш.
   azernot
 
759 - 21.04.21 - 10:30
Мне кажется надо завести отдельную тему для холивара на тему "Что такое Регистр?".
Потому как сейчас многие участники обсуждения (а особенно ТС) понимают под этим понятие каждый что-то своё. А отсюда и все споры.
   Garykom
 
760 - 21.04.21 - 10:30
(758) Угу потому что малая часть данных, для ускорения и полные данные (первичные документы) больше
 
 
   Garykom
 
761 - 21.04.21 - 10:31
(759) Вопрос регистров он близко к вопросу нормализации данных
По сути часть данных дублируется есть первичные документы и еще по ним строятся некие сводные итоги и хранятся помесячно или чаще
   Mikeware
 
762 - 21.04.21 - 10:32
(755) ага. а  brainguard - это доведенный до абсурда  Garykom. ну, или наоборот, что тоже верно.
   Волшебник
 
763 - 21.04.21 - 10:32
(759) Чёткого определения нет. Это древнее латинское слов, когда ещё компьютеров и в помине не было.
По сути любая учётная система может быть регистром. Даже загнутые пальцы на руке могут быть регистром.
   Garykom
 
764 - 21.04.21 - 10:33
(762) что на (757) скажем?
   Garykom
 
766 - 21.04.21 - 10:34
(764)+ представь что запрос к первичным документам для получения итогов делается быстрее (в недалеком будущем) чем время проведения одного документа по регистрам (в прошлом или сейчас)
   Garykom
 
767 - 21.04.21 - 10:35
(765) Ты тоже про MapReduce не в курсе?
А вот в бигдата и крупняк типа оракла и даже вконтакте вовсю юзают
   Garykom
 
768 - 21.04.21 - 10:36
(766)+ За счет того что запрос по документам успешно распараллеливается на допустим десятки тысяч процессов, а проведение одного документа однопоточное
   Paint_NET
 
769 - 21.04.21 - 10:37
(757) Это куда он пропадать стал?
   azernot
 
770 - 21.04.21 - 10:37
(763) Ну о том и речь.
В контексте 1С (мы же о 8.х?) слово "Регистр" использовано  для обозначения специальных механизмов регистрации и агрегации данных: Регистр накопления (остатков и оборотов), Регистр сведений (периодический и непериодический), Регистр расчёта, Регистр бухгалтерии.
У каждого вида "регистра" свой функционал, своё предназначение.

ТС предлагает не использовать этот механизм, а по сути "эмулировать" его с помощью некоторого набора функций мотивируя это какими-то только ему понятными аргументами, отвергая всё остальное.
   Garykom
 
771 - 21.04.21 - 10:39
(769) Спецов по OLAP нет почти, хватает обычного SQL
Инфы новой нет и все решения по OLAP что еще остались и используются они хз каких годов движок с новым только ифейсом/оболочкой
   Cyberhawk
 
772 - 21.04.21 - 10:46
(761) Ты хотел сказать "денормализации"
   Mikeware
 
773 - 21.04.21 - 10:48
(767) в курсе. Есличо, мне книжку по основам этого самого распараллеливания подарили довольно давно, перед армией еще. правда ,тогда нам особо негде это было применять.
(770) а механизм регистров в 1с - это эмуляция кэширования расчетов. Т.е. не "функции калимулина" эмулируют регистр, а регистр эмулирует кэш для ускорения расчетов, выполняющихся "функциями калимулина"
(772) для человека, услышавшего слово "MapReduce" разница между нормализацией и денормализацией пропадает :-)))))
   Paint_NET
 
774 - 21.04.21 - 10:50
(771) Да с чего это вообще? У олапа нет как такового интерфейса, это лишь способ хранения данных. Олап хорош тем, что в нём можно консолидировать уйму данных из разных источников и визуализировать это не отходя от кассы хоть в экселе, хоть в powerbi. Спецов вполне достаточно, и они активно изучают DAX, с которым манипулировать выдернутыми из олап-куба данными гораздо веселее. Ну и, наконец, много ли где в учётных системах используется MapReduce?
   fisher
 
775 - 21.04.21 - 10:51
(758) Нет.
   Cyberhawk
 
776 - 21.04.21 - 10:52
(775) Дашь свое определение кэша?
   fisher
 
777 - 21.04.21 - 10:57
(776) Буфер в быстрой памяти ограниченного размера (по сравнению с источником данных в более медленной памяти), предполагающий наличие стратегий вытеснения.
   johnnik
 
778 - 21.04.21 - 10:57
зачем вообще нужна 1С если есть папирус и глиняные таблички
   PLUT
 
779 - 21.04.21 - 10:59
(776) ДЕНЕЖНЫЕ СРЕДСТВА
   Bigbro
 
780 - 21.04.21 - 11:06
ну а если всерьез подойти к теме которую поднял автор, то можно обойтись без операций на гландах через ... и вообще без 1С.
а все необходимые отчеты (мы ведь знаем точно какие когда и кому понадобятся) - рассылать по почте заранее сформированными.
и кстати подобная рассылка отчетов реально некоторыми организациями используется. разный набор данных формируется по категориям пользователей. удобно к совещаниям, чтобы с утра 50 человек не лопатили лихорадочно базу одними и теми же мега-запросами, а просто открыли готовое и посмотрели.
   piter3
 
781 - 21.04.21 - 11:07
(780) Я не заметил описания сферы применения?Было?
   Bigbro
 
782 - 21.04.21 - 11:09
(781) любая сфера где требуются единообразные громоздкие отчеты большому числу людей.
   azernot
 
783 - 21.04.21 - 11:15
(761) Ну, судя по всему, вы подразумеваете исключительно регистр накопления.
Итак, регистр накопления - это отдельная таблица, в которой в некотором формализованном виде (с набором измерений и ресурсов) записываются движения документа. Эти самые набор измерений и ресурсы рассчитываются как на основе данных самого документа, так и на основе других данных информационной базы. Т.е. сказать, что записи регистра - это дублирование данных только самого документа однозначно нельзя.
И уже дальше на основе этой "таблицы движений" применяются все прочие вкусности, предназначенные для ускорения получения агрегированных данных, разграничения доступа и т.п.

Т.е. даже если мы исключим "вкусности", апеллируя к тому, что это всё лишнее в условиях производительности современной аппаратной базы, сам механизм "расчёта и формирования движений" никуда не денется. Весь вопрос только в том, хранится он где-то в готовом виде, или динамически рассчитывается каждый раз в момент обращения.

(773)>механизм регистров в 1с - это эмуляция кэширования расчетов
Это лишь малая часть функционала "регистров" в 1С. Т.е. использование всяких там индексов, промежуточных итогов, виртуальных таблиц регистра и т.п. "платформенных" фишек регистров - это далеко не всё. Большинство пользователей - это вообще не интересует. Они и могут вообще не знать об этом.
А интересно пользователям  понимание того, что данная конкретная сумма получилась из таких вот конкретных записей, которые сформировали вот эти конкретные документы. Причём не какими-то мега-запутанными "функциями калимулина", а простейшим расчётом в стиле "Остаток на конец = Остаток на начало + Приход за период - Расход за период" в разрезе нужной аналитики.
   acanta
 
784 - 21.04.21 - 11:21
А зачем вам 1с, если у пользователя в должностной инструкции есть график отчетов в екселе которые он получает на почту и отправляет на какой то робот, загружающий данные в базу?
   Mikeware
 
785 - 21.04.21 - 12:05
(780) но ведь что регистр, что "функции калимулина" предполагают пользование чуть более регулярное, чем ограниченное количество отчетов в одно время... Они предполагают частые получения каких-то единичных результатов ("есть ли такой товар в наличии сейчас", "сколько зарезервировано", "сколько из пришедшего товара зарезервировано, и кому", "каков остаток на счете после прошедших поступлений и выплат")
рассылка отчетов - да, это хороший вариант, когда обсуждаемые состояния должны быть синхронизированы (т.е. "все обсуждаем просроченную задолженность клиентов по состоянию на 12:00")
Есть еще вариант - выкладывать обновленный куб данных, и пусть его аналитики крутят - им 1с и регистры не нужны
   azernot
 
786 - 21.04.21 - 12:14
- Лена, ты разнесла выписки за вчера?
- Да, Мария Ивановна!
- Отлично, тогда завтра наконец мы сможем сформировать отчёт о просроченной задолженности по состоянию на сегодня и понять, могли ли мы сегодня отгружать товары тому покупателю, которому мы сегодня зарубили отгрузку...
   Mikeware
 
787 - 21.04.21 - 12:15
(783)"данная конкретная сумма получилась из таких вот конкретных записей, которые сформировали вот эти конкретные документы."  тогда остается вопрос - "как получилась эта запись?". Если эта запись примитивна, и сумма примитивна, то и "сумма записей" (читай - функция калимулина) тоже примитивна. Т.е. пользователю будет понятно без промежуточных значений. а если пользователю непонятно, как формируются записи в регистре (которые потом тупо суммируются) - ему этот регистр не несет особой смысловой нагрузки.
функция в любом случае эквивалентна получению через регистр как промежуточное хранилище.
   Mikeware
 
788 - 21.04.21 - 12:18
(786) именно так. Если информация о событиях появляется с временным лагом - так и происходит.
например, у меня с утра рассылаются отчеты о просрочке с учетом только кассы и первой части выписки банка. а окончательная "дебиторка на начало дня" формируется только после разноски выписки. И действительно, клиенты, "закрытые" за просрочку, могут "открыться"
   azernot
 
789 - 21.04.21 - 12:39
(787) >а если пользователю непонятно, как формируются записи в регистре
Буде возникнет у пользователя такое желание - он разберётся и поймёт. И опять таки, в большинстве ситуаций, это достаточно сделать один раз, научиться доверять механизму и использовать его.

Разумеется всё это зависит от того, как реализовано конкретное решение, как спроектирован конкретный регистр. Но при прочих равных - иметь накладную таблицу всех движений для пользователя лучше, чем не иметь её. Понятно, что и без физических таблиц пользователю можно вывести какой-то отчёт, который просто выведет информацию об этих "виртуальных" записях. Но как я уже говорил, для этого механизму придётся по сути всё пересчитать, виртуально сформировать эти самые движения и вывести их.
Т.е. формирование "движений" (с записью или без оной) в системе при любых вариантах должно быть. Отчёт "Движения документа" - должен быть. Тогда вопрос, кому и чем мешают "регистры" и в чём смысл отказываться от этого механизма?
   azernot
 
790 - 21.04.21 - 12:42
+(789) накладную таблицу  = наглядную таблицу
   SSSSS_AAAAA
 
791 - 21.04.21 - 13:12
(0) Идиотский вопрос, а какую бучу развели...
Какие еще соображения, не связанные с быстродействием, могут быть, если предмет обсуждения был создан только и исключительно для повышения быстродействия?
Вы же не задаетесь вопросом о соображениях, кроме быстродействия, в отношении индексов в таблицах? А регистры в 1с это и есть те же индексы, только на более высоком уровне и не по одной таблице, а по нескольким. Кэши это тоже индексы, только временные и на ограниченном объеме данных.
Во всех случаях некоторая денормализация, дающая очень большой прирост скорости, который компенсирует все остальные недостатки примененной денормализации.
Получение из таблиц готовых/запомненных результатов детерминированной функции всегда быстрее/экономичнее/эффективнее выполнения этих функции, и чем больше данных, тем больше становится разница в этих скоростях. Это идет еще с таблицы умножения, потом таблиц Брадиса и т.д. И все это придумано отнюдь не 1С.
   Mikeware
 
792 - 21.04.21 - 13:13
(789)  "в большинстве ситуаций, это достаточно сделать один раз, научиться доверять механизму и использовать его" - это же самое касается и "функции".
любое "движение" в регистре есть результат функции от документа. каковые результаты потом предварительно суммируются, и записываются в итоги (что, в общем, не обязательно - РС итогов не имеет)

"Понятно, что и без физических таблиц пользователю можно вывести какой-то отчёт, который просто выведет информацию об этих "виртуальных" записях." - т.е. о результатах работы функции. которая либо записала в регистр, либо записала сразу в отчет.

"Тогда вопрос, кому и чем мешают "регистры"" - не знаю.
"и в чём смысл отказываться от этого механизма" а зачем отказываться, если можно не "приказываться"? "давно ли ты отказался пить коньяк по утрам?"
   Mikeware
 
793 - 21.04.21 - 13:16
(791) вопрос идиотский. но и утверждение, что "сли предмет обсуждения был создан только и исключительно для повышения быстродействия" - тоже идиотское. которое переплевывает по степени идиотизма только утверждение, что "регистры в 1с это и есть те же индексы"
   PLUT
 
794 - 21.04.21 - 13:17
(791) только вот в таблице умножения и Брадиса в военное время синус не достигает 4. а в регистрах 1С - запросто :)
   Mikeware
 
795 - 21.04.21 - 13:18
(794) а ты эти регистры напечатай, сшей, прошнуруй и пронумеруй - и они будут неизменны до следующего решения ЦК ВЦСПС.
   PLUT
 
796 - 21.04.21 - 13:20
вот еще тема для обсуждения - зачем нужны константы

и почему константы меняются, хотя смысл константы - постоянная величина, в отличие от переменных
   Mikeware
 
797 - 21.04.21 - 13:21
(796) жестокий ты
   fisher
 
798 - 21.04.21 - 13:22
Регистры - это кэш. Регистры - это индексы. Регистры - это денормализация.
"О сколько нам открытий чудных..." (с)
   SSSSS_AAAAA
 
799 - 21.04.21 - 13:23
(793) Зевс, если ты злишься, то ты неправ.
   Mikeware
 
800 - 21.04.21 - 13:25
(799) куда мне до зевсов...
  1  2  3  4  5  6  7  8  9  10   

Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.