Регистры накопления

@Программист1С · Регистрация: 15.11.2014

Author24 — интернет-сервис помощи студентам

Уважаемые дамы и господа, предлагаю обсудить необходимость и технико-экономическое обоснование использования в конфигурациях 1С регистров накопления:
"Механизм учета движения средств (финансов, товаров, материалов и т.д.) позволяет автоматизировать такие направления, как складской учет, взаиморасчеты, планирование. Основу этого механизма составляют объекты прикладного решения Регистр накопления.
Регистр накопления образует многомерную систему измерений и позволяет "накапливать" числовые данные в разрезе нескольких измерений. Например, в таком регистре можно накапливать информацию об остатках товаров в разрезе номенклатуры и склада, или информацию об объемах продаж в разрезе номенклатуры и подразделения компании..." (http://v8.1c.ru/overview/AccumulationReg.htm)
Уважаемые программисты, согласны ли Вы со следующими утверждениями, имеющими непосредственное отношение практически ко всем конфигурациям 1С?
1. Использование регистров накопления приводит к появлению технически необоснованной избыточности данных в базе, как следствие, увеличению информационного объема базы, что повышает стоимость ее эксплуатации пользователями.
2. Использование регистров накопления, хранящих промежуточные результаты расчетов соответствует информационной модели средств вычислительной техники в СССР уровня 20-80 хх годов ХХ века, когда вычисления производились на счетах, арифмометрах или непрограммируемых калькуляторах, а каждый промежуточный результат записывался на бумажном носителе информации.
3. Использование регистров накопления приводит к возникновению проблемы связанности данных, что проявляется при необходимости корректировки введенных документов и также повышает стоимость ее эксплуатации пользователями.
4. Использование регистров накопления вида (Число 15;2) в случае нормирования стоимости приводит к накоплению ошибок округления распределения стоимости, что приводит к появлению недостоверных результатов.
5. Использование регистров накопления вызывает замедление работы с базой в некоторых случаях многопользовательского режима вследствие возникающих блокировок доступа к данным.
6. Использование регистров накопления противоречит принципу уникальности записи в реляционной базе данных.
В случае несогласия прошу Вас представить аргументированные возражения.

@duk337 · 15.11.2014, 14:22

Программист1С, не по делу выступил:
1. По докам отчеты строить, не говоря о сложной системе учёта?

2. Это без всякой аргументации

3,4,5,6 может прийти в голову только в случае неумения программировать в 1с, незнания SQL и принципа построения объектной БД.

Программист1С, встречный вопрос. Просьба ответить аргументированно и честно как на духу: это троллинг?

Tklwegsd · 15.11.2014, 14:27

Программист1С, Вы расписали минусы использования регистров накопления.
А какие можете предложить плюсы?

@Программист1С · 18.11.2014, 15:32 **[ТС]**

duk337, Вы считаете, что SQL сервер работает с объектными базами данных? Если нет, то в чем смысл Вашего утверждения?
Вам никогда не приходилось задумываться, какую долю в накладных расходах предприятия составляет использование неэффективных программных продуктов независимо от синтаксиса языка на котором они написаны? Известно ли Вам, что программы, реализующие одну и ту же задачу, но написанные на разных языках обладают разной эффективностью? Известно ли Вам, что погрешность суммы измерений равна сумме погрешностей каждого измерения? В любом случае, спасибо за Ваш ответ, хотя я и просил давать аргументированные ответы.

@duk337 · 18.11.2014, 16:03

Сообщение от Программист1С

duk337, Вы считаете, что SQL сервер работает с объектными базами данных? Если нет, то в чем смысл Вашего утверждения?

формат физического хранения данных. Вы просто уверены, что БД 1с хранит числа в символьном виде, а строки занимают столько же места, сколько в прямоугольничке на экране.

Сообщение от Программист1С

Вам никогда не приходилось задумываться, какую долю в накладных расходах предприятия составляет использование неэффективных программных продуктов независимо от синтаксиса языка на котором они написаны?

Это моя профессия, опыт которой говорит, что 1с эффективная платформа.

Сообщение от Программист1С

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

вы на ёкселе пробовали кольцевые ссылки считать? Весело было?[/quote]

Сообщение от Программист1С

Известно ли Вам, что погрешность суммы измерений равна сумме погрешностей каждого измерения?

При чем здесь погрешность? Не понял.
Похоже, у Вас просто мало опыта. В SAP R3 так же используются накопительные компилирующие таблицы, пусть и на Оракле. Собирать данные из первичных документов неэффективно, а зачастую просто невозможно: данные при проведении в регистр могут отличаться от данных в документе.

@Dethmontt · 18.11.2014, 17:26

Сообщение от Программист1С

1. Использование регистров накопления приводит к появлению технически необоснованной избыточности данных в базе, как следствие, увеличению информационного объема базы, что повышает стоимость ее эксплуатации пользователями.

в 1С много что работает не оптимально, зато универсально. иногда приходиться жертвовать чем-то одним ради другого

Сообщение от Программист1С

2. Использование регистров накопления, хранящих промежуточные результаты расчетов соответствует информационной модели средств вычислительной техники в СССР уровня 20-80 хх годов ХХ века, когда вычисления производились на счетах, арифмометрах или непрограммируемых калькуляторах, а каждый промежуточный результат записывался на бумажном носителе информации.

Согласен, но
Плюсы - Более простые и быстрые выборки из агрегированных таблиц
Да, есть способы в реляционных БД более оптимальные для получения этих данных. Но пока за весь мой опыт работы это ни разу не мешало производительности решения (в основном все косяки при написании кода на встроенном языке самими программистами 1С)

Сообщение от Программист1С

3. Использование регистров накопления приводит к возникновению проблемы связанности данных, что проявляется при необходимости корректировки введенных документов и также повышает стоимость ее эксплуатации пользователями.

По моему можно пункт 1 и 3 объединить в 1 пункт...
Иногда так регистры и используют что бы это связности и не было - например когда необходимо изменить показатели не меня данных вводимых человеком, например распределить какую то базу подведенную по итогам какого-то периода и распределить ее на показатели!

Сообщение от Программист1С

4. Использование регистров накопления вида (Число 15;2) в случае нормирования стоимости приводит к накоплению ошибок округления распределения стоимости, что приводит к появлению недостоверных результатов.

Ну это косяк твоих рук, причем тут регистры?, не используй число 15;2 (с типовыми не работаю и мне пофиг как они устроены! ЭТО НЕ ЭТАЛОН!!!)

Сообщение от Программист1С

5. Использование регистров накопления вызывает замедление работы с базой в некоторых случаях многопользовательского режима вследствие возникающих блокировок доступа к данным.

И опять а регистры то тут причем? К любой таблице в СУБД может быть установлена блоктровка

Сообщение от Программист1С

6. Использование регистров накопления противоречит принципу уникальности записи в реляционной базе данных.

Это с какого ??? Тут по подробнее можно?

@Программист1С · 19.11.2014, 12:07 **[ТС]**

"...При чем здесь погрешность?..." поскольку регистры накопления (и остатков и оборотов) представляют из себя таблицы с набегающим итогом, на них распространяются все законы теории погрешностей, в том числе и тот, что ошибка набегающего итога суммы слагаемых равна сумме ошибок слагаемых набегающего итога. Если Вас заинтересовал этот момент, в интернете существует множество публикаций по данному вопросу, например, http://physics.herzen.spb.ru/l... apter1.htm.
"...И опять а регистры то тут причем? К любой таблице в СУБД может быть установлена блоктровка..."
При неоптимальной в смысле избыточности структуре базы количество блокировок возрастает пропорционально избыточности.
"...Это с какого ??? Тут по подробнее можно?..."
"...Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе..." (http://www.wwwmaster.ru/13-int... azy-dannyh). Регистры накопления - это таблицы, представляющие, выражаясь математическим языком, линейный оператор (при этом строго детерминированный, прошу обратить внимание, duk337) над таблицей исходных данных.
"...Вы расписали минусы использования регистров накопления. А какие можете предложить плюсы?..." - мне представляется, что регистры накопления - это принципиальная ошибка авторов 1С, противоречащая всем известным принципам построения реляционных баз данных, принципам организации вычислительных процессов, к тому же существенно увеличивающая стоимость программного продукта для конечного потребителя. Мне не известен ответ на Ваш вопрос, поэтому я и предложил обсудить мою аргументацию.

@wladimir_ui · 19.11.2014, 12:40

Не по теме:

Сообщение от Программист1С

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

представил буха, в ручную калькулирующего движуху по партиям :D

@duk337 · 20.11.2014, 01:09

Программист1С, весь мир остановился на системах типа OLAP. Какого чёрта мы тут разводим полемику? Любые издержки, указываемые Вами, мизерны по сравнению с функциональностью таких систем хранения и обработки.

Добавлено через 3 минуты

Сообщение от Программист1С

ошибка набегающего итога

Вы вообще знакомы с системой расчета остатков или оборотов в 1с? Я к тому, что она оптимизирована, а много букав я пейсать не хочу, посему, разъяснения по отдельному запросу.

Добавлено через 1 час 20 минут

Сообщение от Программист1С

при этом строго детерминированный

сейчас только обратил внимание. Не смешите людей-то. Трудно найти регистр с конкретным типом регистратора. Точнее, это трабл: строго детерминированный регистратор. Это вообще справочник

@Программист1С · 20.11.2014, 11:51 **[ТС]**

"...весь мир остановился на системах типа OLAP..."
Ответ: Если по накоплению ошибок округления более возражений нет, давайте рассмотрим вопрос эффективности использования OLAP. "...Время произвольного доступа (random access time) - время, за которое винчестер гарантированно выполнит операцию чтения или записи на любом участке магнитного диска. Диапазон этого параметра невелик - от 2,5 до 16 мс...." (http://www.itech.am/knowledge-... stics.html). "...Из спецификации RDRAM следует, что время доступа составляет 38,75 нс...." (http://citforum.ru/book/optimize/ram.shtml). "...обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище. ..." (http://www.olap.ru/basic/OLAP_intro1.asp).
Воспользовавшись этими исходными данными, Вы сможете легко найти ответ на следующие вопросы: эффективно ли увеличивать объем базы за счет хранения результатов вычисления линейной функции, а также насколько целесообразно объединять базу данных и OLAP.
"...Трудно найти регистр с конкретным типом регистратора. Точнее, это трабл: строго детерминированный регистратор. Это вообще справочник..."
Ответ: Количество регистраторов определяется эффективностью информационной модели, так, например, в типовой конфигурации 1С:8.2 УПП модель продаж состоит из следующих документов: Заказ покупателя, Корректировка заказа покупателя, Изменение заказа покупателя, Закрытие заказов покупателей, Счет на оплату покупателю, Резервирование товаров, Формирование потребностей, несколько видов Реализации, Корректировка реализации, Возврат товаров от покупателя, Счет-фактура выданный, возможно, я что-то пропустил.

@duk337 · 20.11.2014, 12:31

Сообщение от Программист1С

а также насколько целесообразно объединять базу данных и OLAP.

Мы как слепой с глухим. ОЛАП озвучен мной как абстрактный принцип оптимальной работы в предметной обасти. Отказавшись от принципа промежуточной компиляции данных, вы убьёте любую экономическую прикладную систему. Прежде всего - её способность выполнять экономические функции, прикладные алгоритмы.
Но даже технически система ляжет, когда хотя бы 100 человек начнут перебирать все детальные записи БД.
А в 1с с регистрами всё хитрее и оптимальнее, чем кажется на первый взгляд, чем кажется, когда теоретизируешь про ОЛАП. Практика - критерий истины.

Сообщение от Программист1С

Количество регистраторов определяется эффективностью информационной модели

Наоборот: эффективность информационной модели не ограничивает количество регистраторов. Я рад, что Вы заморочились с анализом списка регистраторов. Десятки расчетов требуют готовой информации по всему списку этих регистраторов, и - заметьте! - без их участия, поскольку линейные данные не аксиома в реальном времени.
Ну давайте пример для продвинутых: отгрузка, остаток необходим по каждой строке. Документы лежат за пару лет. Десяток типов приходных, столько же расходных. И что: помчимся +Приход -Расход от царя гороха? Вы это предлагаете? Мне даже пейсать об этом неловко. Что у Вас за идея в голове, может, поделитесь? Откроем терра инкогнита, назовём "нано-учёт" и повесим медаль на грудь.
Я вот что скажу. Когда создавалась платформа 8, было натырено всё лучшее из мировой практики. Натырено и улучшено по мере сил. Пусть некоторые товарищи поржут, но с точки зрения ядра учетной модели - именно регистров накопления - с более удачными решениями я не сталкивался. С менее удаными - сколько угодно.
PS. Время жалко на объяснения, что такое стакан. Или, там, рюмка. Особенно если оппонент считает, что стакан - это запаянный сверху стеклянный цилиндр без дна.

@Dethmontt · 21.11.2014, 00:22

Сообщение от Программист1С

"...Это с какого ??? Тут по подробнее можно?..."
"

Сообщение от Программист1С

...Главная цель нормализации базы данных - устранение избыточности и дублирования информации.

Я вообще-то спросил про:

Сообщение от Dethmontt

Использование регистров накопления противоречит принципу уникальности записи в реляционной базе данных

Вы мне начинаете опять про нормализацию и избыточность данных...Я спросил что чему противоречит?

Сообщение от Программист1С

...Главная цель нормализации базы данных - устранение избыточности и дублирования информации.

А денормализация вам такой термин известен?
https://ru.wikipedia.org/wiki/... 0%F6%E8%FF

Добавлено через 3 минуты
http://habrahabr.ru/post/64524/

Добавлено через 13 минут
Процитирую:

Частота запросов и устойчивость производительности.

Например, 70% из 1000 запросов, ежедневно генерируемых предприятием, представляют собой запросы уровня сводных, а не детальных данных. При использовании таблицы сводных данных запросы выполняются примерно за 6 секунд вместо 4 минут, т.е. время обработки меньше на 2730 минут. Даже с поправкой на те 105 минут, которые необходимо еженедельно тратить на поддержку таблиц сводных данных, в итоге экономится 2625 минут в неделю, что полностью оправдывает создание таблицы сводных данных. Со временем может случиться так, что большая часть запросов будет обращена не к сводным данным, а к детальным данным. Чем меньше число запросов, использующих таблицу сводных данных, тем проще от нее отказаться, не затрагивая другие процессы.

@Программист1С · 21.11.2014, 02:05 **[ТС]**

Уважаемые duk337 и Dethmontt, предмет нашего обсуждения относится к точным наукам, а утверждение либо истинно, либо ложно. Предлагаю обсчитать конкретную модель и сравнить полученные количественные характеристики. Рассмотрим для примера торговую организацию, 100 продаж в день, в каждом документе более 100 строк. Аналитические отчеты используются редко, зато детальные товарные остатки в т.ч. партионные необходимы постоянно. Все отчеты формируются одновременно с вводом (и проведением) документов. В базе хранятся данные за последние два года работы. Прошу Вас представить ориентировочный расчет стоимости оборудования и необходимых программных средств, а также дать Ваши оценки быстродействия и сравнительной эффективности работы программы в вариантах с использованием регистров накопления и без них.

@Dethmontt · 21.11.2014, 02:39

Т.е. предполагаем что в базе есть и возвраты и перемещения и корректировки существующих документов в текущем периоде (что сложнее реализовать не дублируя данные), а так же разукомплектации, списание, продажи, поступления, резервирование, заказы покупателей и т.д. (можешь продолжить список, т.к. ты его уже знаешь)

То использование регистра накоплений целесообразно даже для детальных записей.

Не по теме:

Честно, мне лень тебе это доказывать на примере...

Добавлено через 3 минуты

Не по теме:

Программист1С, а для одного документа (ну или двух) регистр и нафиг не нужен
Хотя для получения каких либо сумм придется использовать агрегатные функции которые дорогие сами по себе, но тут уже нужно определяться что тебе дороже чтение или запись

И еще раз повторюсь:

Сообщение от Dethmontt

иногда приходиться жертвовать чем-то одним ради другого

Не по теме:

соглашусь все-таки с duk337 тема тупой вброс...

Добавлено через 11 минут
Есть статья на инфостарте: http://infostart.ru/public/269803/

мне понравился один комментарий к статье:

Мне трудно говорить о минусах нормализации...
это скорее процесс эволюции перехода от хаоса к нормализации, от нормализации к денормализации.

Я бы говорил о плюсах денормализации, как осознанных шагов после нормализации.

И все же, если говорить об ограничениях, то:
1.Нормальные формы больше подходят к статике, чем к динамике.
2.Нормальные формы имеют большее количество таблиц, что создает иллюзию сложности.
3.Чрезмерное увлечение ограничениями NOT NULL ухудшает юзабельность приложения.
4.Принцип "одна сущность - одна основная таблица" ограничивает универсальность решения.

Ну, а в остальном... главное - это обойтись без фанатизма.
Нормальные формы - это всего лишь еще одна полезная модель.
(с) Evgen.Ponomarenko

@duk337 · 21.11.2014, 13:24

Сообщение от Программист1С

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

Не ранее 2-го квартала 2020 года, посколько создать систему без регистров затруднительно.
А вообще, мне этот троллинг уже приелся. Не знаю, как ТС, а я не дятел, чтоб долбить одно и то же.

@Программист1С · 23.11.2014, 14:29 **[ТС]**

"...создать систему без регистров затруднительно. А вообще, мне этот троллинг уже приелся..."
Ответ: уважаемый duk337, Ваше утверждение о затруднениях в создании системы без регистров голословно и ошибочно, взгляните, например, на учебную базу "Борей" из MS Access. Хотел бы напомнить, что я предлагал представить аргументированные возражения на предлагаемый подход к регистрам накопления. Что из Ваших публикаций можно рассматривать в качестве аргументированных возражений, а не в качестве отказа от обсуждения истинного положения вещей, недомолвок, отказа от рациональной аргументации, подмены тезиса, и даже заведомо ложных утверждений? В любом случае благодарю Вас за участие в дискуссии, надеюсь, она принесла Вам пользу, хотя бы в понимании некоторых вопросов теории погрешностей.

@Программист1С · 26.11.2014, 11:45 **[ТС]**

"...Т.е. предполагаем что в базе есть и возвраты и перемещения и корректировки существующих документов в текущем периоде (что сложнее реализовать не дублируя данные), а так же разукомплектации, списание, продажи, поступления, резервирование, заказы покупателей и т.д. (можешь продолжить список, т.к. ты его уже знаешь)
То использование регистра накоплений целесообразно даже для детальных записей...."
Ответ: Уважаемый Dethmontt, я согласен с тем, что выборка данных из одной таблицы эффективней, чем выборка данных из нескольких таблиц, вопрос в том, являются ли регистры накопления решением данной проблемы? Практика показывает, что структура стандартных регистров накопления удовлетворяет потребности пользователей очень редко. Как только начинается выборка каких-либо дополнительных реквизитов измерений (по ссылкам) начинается выборка из нескольких таблиц и теряется всякий смысл использования регистров накопления. Хотел бы обратить Ваше внимание, что использование СУБД в целях эффективного управления предприятием предполагает не только выборку данных из неких универсальных таблиц, но и решение ряда практических задач, например, текущей оценки товарных запасов в режиме, близком к реальному времени. Хотел бы обратить Ваше внимание, что в случае ненормализованной структуры базы выборка данных замедляется избыточным количеством блокировок доступа к данным, особенно, если эта выборка производится одновременно с вводом и проведением документов. Хотел бы обратить Ваше внимание, что ни в одной типовой конфигурации 1С не разрешена следующая коллизия: два и более менеджеров одновременно оформляют документы продажи, каждый своему контрагенту. На момент начала оформления остаток по Товар1 составляет 10 единиц, остаток по Товар2 составляет 8 единиц. Первый менеджер заполняет продажу 9 единиц Товара1 и 7 единиц Товара2, второй менеджер заполняет продажу 6 единиц Товара 2 и 8 единиц Товара 1, затем они начинают проведение документов по регистрам накопления. При проведении документов обнаруживается дефицит Товара1 и дефицит Товара2 (расчет текущего остатка производится по данным регистров накопления), документы не проводятся (часто требуется перезагрузка сервера), работа предприятия останавливается.
Предлагаю выполнить следующий мысленный эксперимент: предприятие купило новый сервер, установило чистую базу и начало вести управление по данным этой базы. По мере заполнения базы объем данных увеличивается, соответственно увеличивается объем использования файла подкачки, также увеличивается время выполнения операций с базой. В типовой 1С 8.2 УПП документ "РеализацияТоваровУслуг" формирует движения по 43 (Сорока трем) регистрам накопления, примем заниженную оценку коэффициента избыточности, равную 5. Вопросы: во сколько раз требуется повысить быстродействие сервера, по сравнению с сервером для базы без избыточности для обеспечения одинакового быстродействия? Во сколько раз повысится стоимость такого сервера (или кластера серверов)?
Учитывая, что время выборки данных примерно на 5 десятичных порядков (в сотни тысяч раз) медленнее, чем выполнение алгебраических операций над данными, эффективность использования регистров накопления, хранящих результаты вычисления линейной функции(!), можно оценить, как величину, близкую к нулю.
Прошу Вас дать обоснование Вашему утверждению об эффективности использования регистров накопления.

@Dethmontt · 26.11.2014, 11:57

Сообщение от Программист1С

Прошу Вас дать обоснование Вашему утверждению об эффективности использования регистров накопления.

Да надоело уже переливать из пустового в порожнее...

Не по теме:

З.Ы. Если бы все было так плохо как вы пишите, то никто бы не пользовался программами 1С давно бы появилась более дешевая альтернатива
З.Ы.Ы 1С УПП довольно старый продукт, берите в пример лучше 1С ЕРП 2.0

Добавлено через 1 минуту

Не по теме:

З.Ы.Ы.Ы. Главный критерий - решение работает!

@duk337 · 26.11.2014, 12:21

Сотый раз: регистры накопления решают прикладной фунционал. И тут издержки - штатный, минимально необходимый материал.
Вы бы заглянули в базы оракла решений SAP и OracleApplications. Та же песня. А как ещё?!!
Интересно, конечно, слышать критику математика бухгалтерских алгоритмов, но такая развлекуха типа посетить кунсткамеру - должна быть одноразовой.
Программист1С, предложите решение, хотя бы на словах, хотя бы отгрузки-оплаты (решение для экзамена) без регистров склада и взаиморасчетов. Уж про себестомость, НДС и пр. - замнём для ясности.

@Программист1С · 26.11.2014, 13:02 **[ТС]**

"...предложите решение, хотя бы на словах, хотя бы отгрузки-оплаты (решение для экзамена) без регистров склада и взаиморасчетов..."
Уважаемый Duk337, почему бы Вам все таки не заглянуть в учебную базу "Борей"? Почему бы Вам не произвести прикидки экономической эффективности использования регистров накопления? То, что Вы называете "развлекухой", на практике представляет существенные затраты для многих неквалифицированных покупателей программных продуктов 1С. Кто, кроме специалистов в данном вопросе, может дать независимую оценку недостатков этого программного продукта?

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
		1
	1C 8.x Регистры накопления 15.11.2014, 13:48. Показов 4620. Ответов 40 Метки нет (Все метки) Уважаемые дамы и господа, предлагаю обсудить необходимость и технико-экономическое обоснование использования в конфигурациях 1С регистров накопления: "Механизм учета движения средств (финансов, товаров, материалов и т.д.) позволяет автоматизировать такие направления, как складской учет, взаиморасчеты, планирование. Основу этого механизма составляют объекты прикладного решения Регистр накопления. Регистр накопления образует многомерную систему измерений и позволяет "накапливать" числовые данные в разрезе нескольких измерений. Например, в таком регистре можно накапливать информацию об остатках товаров в разрезе номенклатуры и склада, или информацию об объемах продаж в разрезе номенклатуры и подразделения компании..." (http://v8.1c.ru/overview/AccumulationReg.htm) Уважаемые программисты, согласны ли Вы со следующими утверждениями, имеющими непосредственное отношение практически ко всем конфигурациям 1С? 1. Использование регистров накопления приводит к появлению технически необоснованной избыточности данных в базе, как следствие, увеличению информационного объема базы, что повышает стоимость ее эксплуатации пользователями. 2. Использование регистров накопления, хранящих промежуточные результаты расчетов соответствует информационной модели средств вычислительной техники в СССР уровня 20-80 хх годов ХХ века, когда вычисления производились на счетах, арифмометрах или непрограммируемых калькуляторах, а каждый промежуточный результат записывался на бумажном носителе информации. 3. Использование регистров накопления приводит к возникновению проблемы связанности данных, что проявляется при необходимости корректировки введенных документов и также повышает стоимость ее эксплуатации пользователями. 4. Использование регистров накопления вида (Число 15;2) в случае нормирования стоимости приводит к накоплению ошибок округления распределения стоимости, что приводит к появлению недостоверных результатов. 5. Использование регистров накопления вызывает замедление работы с базой в некоторых случаях многопользовательского режима вследствие возникающих блокировок доступа к данным. 6. Использование регистров накопления противоречит принципу уникальности записи в реляционной базе данных. В случае несогласия прошу Вас представить аргументированные возражения. 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	15.11.2014, 14:22	2
	Программист1С, не по делу выступил: 1. По докам отчеты строить, не говоря о сложной системе учёта? 2. Это без всякой аргументации 3,4,5,6 может прийти в голову только в случае неумения программировать в 1с, незнания SQL и принципа построения объектной БД. Программист1С, встречный вопрос. Просьба ответить аргументированно и честно как на духу: это троллинг? 0

Tklwegsd 844 / 607 / 211 Регистрация: 24.07.2013 Сообщений: 2,102
	15.11.2014, 14:27	3
	Программист1С, Вы расписали минусы использования регистров накопления. А какие можете предложить плюсы? 0

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
	18.11.2014, 15:32 [ТС]	4
	duk337, Вы считаете, что SQL сервер работает с объектными базами данных? Если нет, то в чем смысл Вашего утверждения? Вам никогда не приходилось задумываться, какую долю в накладных расходах предприятия составляет использование неэффективных программных продуктов независимо от синтаксиса языка на котором они написаны? Известно ли Вам, что программы, реализующие одну и ту же задачу, но написанные на разных языках обладают разной эффективностью? Известно ли Вам, что погрешность суммы измерений равна сумме погрешностей каждого измерения? В любом случае, спасибо за Ваш ответ, хотя я и просил давать аргументированные ответы. 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	18.11.2014, 16:03	5
	Сообщение от Программист1С duk337, Вы считаете, что SQL сервер работает с объектными базами данных? Если нет, то в чем смысл Вашего утверждения? формат физического хранения данных. Вы просто уверены, что БД 1с хранит числа в символьном виде, а строки занимают столько же места, сколько в прямоугольничке на экране. Сообщение от Программист1С Вам никогда не приходилось задумываться, какую долю в накладных расходах предприятия составляет использование неэффективных программных продуктов независимо от синтаксиса языка на котором они написаны? Это моя профессия, опыт которой говорит, что 1с эффективная платформа. Сообщение от Программист1С Известно ли Вам, что программы, реализующие одну и ту же задачу, но написанные на разных языках обладают разной эффективностью? вы на ёкселе пробовали кольцевые ссылки считать? Весело было?[/quote] Сообщение от Программист1С Известно ли Вам, что погрешность суммы измерений равна сумме погрешностей каждого измерения? При чем здесь погрешность? Не понял. Похоже, у Вас просто мало опыта. В SAP R3 так же используются накопительные компилирующие таблицы, пусть и на Оракле. Собирать данные из первичных документов неэффективно, а зачастую просто невозможно: данные при проведении в регистр могут отличаться от данных в документе. 0

@Dethmontt Модератор 4029 / 2974 / 591 Регистрация: 10.03.2011 Сообщений: 11,702 Записей в блоге: 1
	18.11.2014, 17:26	6
	Сообщение от Программист1С 1. Использование регистров накопления приводит к появлению технически необоснованной избыточности данных в базе, как следствие, увеличению информационного объема базы, что повышает стоимость ее эксплуатации пользователями. в 1С много что работает не оптимально, зато универсально. иногда приходиться жертвовать чем-то одним ради другого Сообщение от Программист1С 2. Использование регистров накопления, хранящих промежуточные результаты расчетов соответствует информационной модели средств вычислительной техники в СССР уровня 20-80 хх годов ХХ века, когда вычисления производились на счетах, арифмометрах или непрограммируемых калькуляторах, а каждый промежуточный результат записывался на бумажном носителе информации. Согласен, но Плюсы - Более простые и быстрые выборки из агрегированных таблиц Да, есть способы в реляционных БД более оптимальные для получения этих данных. Но пока за весь мой опыт работы это ни разу не мешало производительности решения (в основном все косяки при написании кода на встроенном языке самими программистами 1С) Сообщение от Программист1С 3. Использование регистров накопления приводит к возникновению проблемы связанности данных, что проявляется при необходимости корректировки введенных документов и также повышает стоимость ее эксплуатации пользователями. По моему можно пункт 1 и 3 объединить в 1 пункт... Иногда так регистры и используют что бы это связности и не было - например когда необходимо изменить показатели не меня данных вводимых человеком, например распределить какую то базу подведенную по итогам какого-то периода и распределить ее на показатели! Сообщение от Программист1С 4. Использование регистров накопления вида (Число 15;2) в случае нормирования стоимости приводит к накоплению ошибок округления распределения стоимости, что приводит к появлению недостоверных результатов. Ну это косяк твоих рук, причем тут регистры?, не используй число 15;2 (с типовыми не работаю и мне пофиг как они устроены! ЭТО НЕ ЭТАЛОН!!!) Сообщение от Программист1С 5. Использование регистров накопления вызывает замедление работы с базой в некоторых случаях многопользовательского режима вследствие возникающих блокировок доступа к данным. И опять а регистры то тут причем? К любой таблице в СУБД может быть установлена блоктровка Сообщение от Программист1С 6. Использование регистров накопления противоречит принципу уникальности записи в реляционной базе данных. Это с какого ??? Тут по подробнее можно? 0

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
	19.11.2014, 12:07 [ТС]	7
	"...При чем здесь погрешность?..." поскольку регистры накопления (и остатков и оборотов) представляют из себя таблицы с набегающим итогом, на них распространяются все законы теории погрешностей, в том числе и тот, что ошибка набегающего итога суммы слагаемых равна сумме ошибок слагаемых набегающего итога. Если Вас заинтересовал этот момент, в интернете существует множество публикаций по данному вопросу, например, http://physics.herzen.spb.ru/l... apter1.htm. "...И опять а регистры то тут причем? К любой таблице в СУБД может быть установлена блоктровка..." При неоптимальной в смысле избыточности структуре базы количество блокировок возрастает пропорционально избыточности. "...Это с какого ??? Тут по подробнее можно?..." "...Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе..." (http://www.wwwmaster.ru/13-int... azy-dannyh). Регистры накопления - это таблицы, представляющие, выражаясь математическим языком, линейный оператор (при этом строго детерминированный, прошу обратить внимание, duk337) над таблицей исходных данных. "...Вы расписали минусы использования регистров накопления. А какие можете предложить плюсы?..." - мне представляется, что регистры накопления - это принципиальная ошибка авторов 1С, противоречащая всем известным принципам построения реляционных баз данных, принципам организации вычислительных процессов, к тому же существенно увеличивающая стоимость программного продукта для конечного потребителя. Мне не известен ответ на Ваш вопрос, поэтому я и предложил обсудить мою аргументацию. 0

@wladimir_ui
	19.11.2014, 12:40 #8
	Не по теме: Сообщение от Программист1С причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе представил буха, в ручную калькулирующего движуху по партиям :D 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	20.11.2014, 01:09	9
	Программист1С, весь мир остановился на системах типа OLAP. Какого чёрта мы тут разводим полемику? Любые издержки, указываемые Вами, мизерны по сравнению с функциональностью таких систем хранения и обработки. Добавлено через 3 минуты Сообщение от Программист1С ошибка набегающего итога Вы вообще знакомы с системой расчета остатков или оборотов в 1с? Я к тому, что она оптимизирована, а много букав я пейсать не хочу, посему, разъяснения по отдельному запросу. Добавлено через 1 час 20 минут Сообщение от Программист1С при этом строго детерминированный сейчас только обратил внимание. Не смешите людей-то. Трудно найти регистр с конкретным типом регистратора. Точнее, это трабл: строго детерминированный регистратор. Это вообще справочник 0

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
	20.11.2014, 11:51 [ТС]	10
	"...весь мир остановился на системах типа OLAP..." Ответ: Если по накоплению ошибок округления более возражений нет, давайте рассмотрим вопрос эффективности использования OLAP. "...Время произвольного доступа (random access time) - время, за которое винчестер гарантированно выполнит операцию чтения или записи на любом участке магнитного диска. Диапазон этого параметра невелик - от 2,5 до 16 мс...." (http://www.itech.am/knowledge-... stics.html). "...Из спецификации RDRAM следует, что время доступа составляет 38,75 нс...." (http://citforum.ru/book/optimize/ram.shtml). "...обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище. ..." (http://www.olap.ru/basic/OLAP_intro1.asp). Воспользовавшись этими исходными данными, Вы сможете легко найти ответ на следующие вопросы: эффективно ли увеличивать объем базы за счет хранения результатов вычисления линейной функции, а также насколько целесообразно объединять базу данных и OLAP. "...Трудно найти регистр с конкретным типом регистратора. Точнее, это трабл: строго детерминированный регистратор. Это вообще справочник..." Ответ: Количество регистраторов определяется эффективностью информационной модели, так, например, в типовой конфигурации 1С:8.2 УПП модель продаж состоит из следующих документов: Заказ покупателя, Корректировка заказа покупателя, Изменение заказа покупателя, Закрытие заказов покупателей, Счет на оплату покупателю, Резервирование товаров, Формирование потребностей, несколько видов Реализации, Корректировка реализации, Возврат товаров от покупателя, Счет-фактура выданный, возможно, я что-то пропустил. 0

	26.11.2014, 13:02

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	20.11.2014, 12:31	11
	Сообщение от Программист1С а также насколько целесообразно объединять базу данных и OLAP. Мы как слепой с глухим. ОЛАП озвучен мной как абстрактный принцип оптимальной работы в предметной обасти. Отказавшись от принципа промежуточной компиляции данных, вы убьёте любую экономическую прикладную систему. Прежде всего - её способность выполнять экономические функции, прикладные алгоритмы. Но даже технически система ляжет, когда хотя бы 100 человек начнут перебирать все детальные записи БД. А в 1с с регистрами всё хитрее и оптимальнее, чем кажется на первый взгляд, чем кажется, когда теоретизируешь про ОЛАП. Практика - критерий истины. Сообщение от Программист1С Количество регистраторов определяется эффективностью информационной модели Наоборот: эффективность информационной модели не ограничивает количество регистраторов. Я рад, что Вы заморочились с анализом списка регистраторов. Десятки расчетов требуют готовой информации по всему списку этих регистраторов, и - заметьте! - без их участия, поскольку линейные данные не аксиома в реальном времени. Ну давайте пример для продвинутых: отгрузка, остаток необходим по каждой строке. Документы лежат за пару лет. Десяток типов приходных, столько же расходных. И что: помчимся +Приход -Расход от царя гороха? Вы это предлагаете? Мне даже пейсать об этом неловко. Что у Вас за идея в голове, может, поделитесь? Откроем терра инкогнита, назовём "нано-учёт" и повесим медаль на грудь. Я вот что скажу. Когда создавалась платформа 8, было натырено всё лучшее из мировой практики. Натырено и улучшено по мере сил. Пусть некоторые товарищи поржут, но с точки зрения ядра учетной модели - именно регистров накопления - с более удачными решениями я не сталкивался. С менее удаными - сколько угодно. PS. Время жалко на объяснения, что такое стакан. Или, там, рюмка. Особенно если оппонент считает, что стакан - это запаянный сверху стеклянный цилиндр без дна. 0

@Dethmontt Модератор 4029 / 2974 / 591 Регистрация: 10.03.2011 Сообщений: 11,702 Записей в блоге: 1
	21.11.2014, 00:22	12
	Сообщение от Программист1С "...Это с какого ??? Тут по подробнее можно?..." " Сообщение от Программист1С ...Главная цель нормализации базы данных - устранение избыточности и дублирования информации. Я вообще-то спросил про: Сообщение от Dethmontt Использование регистров накопления противоречит принципу уникальности записи в реляционной базе данных Вы мне начинаете опять про нормализацию и избыточность данных...Я спросил что чему противоречит? Сообщение от Программист1С ...Главная цель нормализации базы данных - устранение избыточности и дублирования информации. А денормализация вам такой термин известен? https://ru.wikipedia.org/wiki/... 0%F6%E8%FF Добавлено через 3 минуты http://habrahabr.ru/post/64524/ Добавлено через 13 минут Процитирую: Частота запросов и устойчивость производительности. Например, 70% из 1000 запросов, ежедневно генерируемых предприятием, представляют собой запросы уровня сводных, а не детальных данных. При использовании таблицы сводных данных запросы выполняются примерно за 6 секунд вместо 4 минут, т.е. время обработки меньше на 2730 минут. Даже с поправкой на те 105 минут, которые необходимо еженедельно тратить на поддержку таблиц сводных данных, в итоге экономится 2625 минут в неделю, что полностью оправдывает создание таблицы сводных данных. Со временем может случиться так, что большая часть запросов будет обращена не к сводным данным, а к детальным данным. Чем меньше число запросов, использующих таблицу сводных данных, тем проще от нее отказаться, не затрагивая другие процессы. 0

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
	21.11.2014, 02:05 [ТС]	13
	Уважаемые duk337 и Dethmontt, предмет нашего обсуждения относится к точным наукам, а утверждение либо истинно, либо ложно. Предлагаю обсчитать конкретную модель и сравнить полученные количественные характеристики. Рассмотрим для примера торговую организацию, 100 продаж в день, в каждом документе более 100 строк. Аналитические отчеты используются редко, зато детальные товарные остатки в т.ч. партионные необходимы постоянно. Все отчеты формируются одновременно с вводом (и проведением) документов. В базе хранятся данные за последние два года работы. Прошу Вас представить ориентировочный расчет стоимости оборудования и необходимых программных средств, а также дать Ваши оценки быстродействия и сравнительной эффективности работы программы в вариантах с использованием регистров накопления и без них. 0

@Dethmontt Модератор 4029 / 2974 / 591 Регистрация: 10.03.2011 Сообщений: 11,702 Записей в блоге: 1
	21.11.2014, 02:39	14
	Т.е. предполагаем что в базе есть и возвраты и перемещения и корректировки существующих документов в текущем периоде (что сложнее реализовать не дублируя данные), а так же разукомплектации, списание, продажи, поступления, резервирование, заказы покупателей и т.д. (можешь продолжить список, т.к. ты его уже знаешь) То использование регистра накоплений целесообразно даже для детальных записей. Не по теме: Честно, мне лень тебе это доказывать на примере... Добавлено через 3 минуты Не по теме: Программист1С, а для одного документа (ну или двух) регистр и нафиг не нужен Хотя для получения каких либо сумм придется использовать агрегатные функции которые дорогие сами по себе, но тут уже нужно определяться что тебе дороже чтение или запись И еще раз повторюсь: Сообщение от Dethmontt иногда приходиться жертвовать чем-то одним ради другого Не по теме: соглашусь все-таки с duk337 тема тупой вброс... Добавлено через 11 минут Есть статья на инфостарте: http://infostart.ru/public/269803/ мне понравился один комментарий к статье: Мне трудно говорить о минусах нормализации... это скорее процесс эволюции перехода от хаоса к нормализации, от нормализации к денормализации. Я бы говорил о плюсах денормализации, как осознанных шагов после нормализации. И все же, если говорить об ограничениях, то: 1.Нормальные формы больше подходят к статике, чем к динамике. 2.Нормальные формы имеют большее количество таблиц, что создает иллюзию сложности. 3.Чрезмерное увлечение ограничениями NOT NULL ухудшает юзабельность приложения. 4.Принцип "одна сущность - одна основная таблица" ограничивает универсальность решения. Ну, а в остальном... главное - это обойтись без фанатизма. Нормальные формы - это всего лишь еще одна полезная модель. (с) Evgen.Ponomarenko 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	21.11.2014, 13:24	15
	Сообщение от Программист1С Прошу Вас представить ориентировочный расчет стоимости оборудования и необходимых программных средств, а также дать Ваши оценки быстродействия и сравнительной эффективности работы программы в вариантах с использованием регистров накопления и без них. Не ранее 2-го квартала 2020 года, посколько создать систему без регистров затруднительно. А вообще, мне этот троллинг уже приелся. Не знаю, как ТС, а я не дятел, чтоб долбить одно и то же. 0

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
	23.11.2014, 14:29 [ТС]	16
	"...создать систему без регистров затруднительно. А вообще, мне этот троллинг уже приелся..." Ответ: уважаемый duk337, Ваше утверждение о затруднениях в создании системы без регистров голословно и ошибочно, взгляните, например, на учебную базу "Борей" из MS Access. Хотел бы напомнить, что я предлагал представить аргументированные возражения на предлагаемый подход к регистрам накопления. Что из Ваших публикаций можно рассматривать в качестве аргументированных возражений, а не в качестве отказа от обсуждения истинного положения вещей, недомолвок, отказа от рациональной аргументации, подмены тезиса, и даже заведомо ложных утверждений? В любом случае благодарю Вас за участие в дискуссии, надеюсь, она принесла Вам пользу, хотя бы в понимании некоторых вопросов теории погрешностей. 0

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
	26.11.2014, 11:45 [ТС]	17
	"...Т.е. предполагаем что в базе есть и возвраты и перемещения и корректировки существующих документов в текущем периоде (что сложнее реализовать не дублируя данные), а так же разукомплектации, списание, продажи, поступления, резервирование, заказы покупателей и т.д. (можешь продолжить список, т.к. ты его уже знаешь) То использование регистра накоплений целесообразно даже для детальных записей...." Ответ: Уважаемый Dethmontt, я согласен с тем, что выборка данных из одной таблицы эффективней, чем выборка данных из нескольких таблиц, вопрос в том, являются ли регистры накопления решением данной проблемы? Практика показывает, что структура стандартных регистров накопления удовлетворяет потребности пользователей очень редко. Как только начинается выборка каких-либо дополнительных реквизитов измерений (по ссылкам) начинается выборка из нескольких таблиц и теряется всякий смысл использования регистров накопления. Хотел бы обратить Ваше внимание, что использование СУБД в целях эффективного управления предприятием предполагает не только выборку данных из неких универсальных таблиц, но и решение ряда практических задач, например, текущей оценки товарных запасов в режиме, близком к реальному времени. Хотел бы обратить Ваше внимание, что в случае ненормализованной структуры базы выборка данных замедляется избыточным количеством блокировок доступа к данным, особенно, если эта выборка производится одновременно с вводом и проведением документов. Хотел бы обратить Ваше внимание, что ни в одной типовой конфигурации 1С не разрешена следующая коллизия: два и более менеджеров одновременно оформляют документы продажи, каждый своему контрагенту. На момент начала оформления остаток по Товар1 составляет 10 единиц, остаток по Товар2 составляет 8 единиц. Первый менеджер заполняет продажу 9 единиц Товара1 и 7 единиц Товара2, второй менеджер заполняет продажу 6 единиц Товара 2 и 8 единиц Товара 1, затем они начинают проведение документов по регистрам накопления. При проведении документов обнаруживается дефицит Товара1 и дефицит Товара2 (расчет текущего остатка производится по данным регистров накопления), документы не проводятся (часто требуется перезагрузка сервера), работа предприятия останавливается. Предлагаю выполнить следующий мысленный эксперимент: предприятие купило новый сервер, установило чистую базу и начало вести управление по данным этой базы. По мере заполнения базы объем данных увеличивается, соответственно увеличивается объем использования файла подкачки, также увеличивается время выполнения операций с базой. В типовой 1С 8.2 УПП документ "РеализацияТоваровУслуг" формирует движения по 43 (Сорока трем) регистрам накопления, примем заниженную оценку коэффициента избыточности, равную 5. Вопросы: во сколько раз требуется повысить быстродействие сервера, по сравнению с сервером для базы без избыточности для обеспечения одинакового быстродействия? Во сколько раз повысится стоимость такого сервера (или кластера серверов)? Учитывая, что время выборки данных примерно на 5 десятичных порядков (в сотни тысяч раз) медленнее, чем выполнение алгебраических операций над данными, эффективность использования регистров накопления, хранящих результаты вычисления линейной функции(!), можно оценить, как величину, близкую к нулю. Прошу Вас дать обоснование Вашему утверждению об эффективности использования регистров накопления. 0

@Dethmontt Модератор 4029 / 2974 / 591 Регистрация: 10.03.2011 Сообщений: 11,702 Записей в блоге: 1
	26.11.2014, 11:57	18
	Сообщение от Программист1С Прошу Вас дать обоснование Вашему утверждению об эффективности использования регистров накопления. Да надоело уже переливать из пустового в порожнее... Не по теме: З.Ы. Если бы все было так плохо как вы пишите, то никто бы не пользовался программами 1С давно бы появилась более дешевая альтернатива З.Ы.Ы 1С УПП довольно старый продукт, берите в пример лучше 1С ЕРП 2.0 Добавлено через 1 минуту Не по теме: З.Ы.Ы.Ы. Главный критерий - решение работает! 0

@duk337 2955 / 1767 / 82 Регистрация: 03.11.2011 Сообщений: 8,280
	26.11.2014, 12:21	19
	Сотый раз: регистры накопления решают прикладной фунционал. И тут издержки - штатный, минимально необходимый материал. Вы бы заглянули в базы оракла решений SAP и OracleApplications. Та же песня. А как ещё?!! Интересно, конечно, слышать критику математика бухгалтерских алгоритмов, но такая развлекуха типа посетить кунсткамеру - должна быть одноразовой. Программист1С, предложите решение, хотя бы на словах, хотя бы отгрузки-оплаты (решение для экзамена) без регистров склада и взаиморасчетов. Уж про себестомость, НДС и пр. - замнём для ясности. 0

@Программист1С 0 / 0 / 0 Регистрация: 15.11.2014 Сообщений: 15
	26.11.2014, 13:02 [ТС]	20
	"...предложите решение, хотя бы на словах, хотя бы отгрузки-оплаты (решение для экзамена) без регистров склада и взаиморасчетов..." Уважаемый Duk337, почему бы Вам все таки не заглянуть в учебную базу "Борей"? Почему бы Вам не произвести прикидки экономической эффективности использования регистров накопления? То, что Вы называете "развлекухой", на практике представляет существенные затраты для многих неквалифицированных покупателей программных продуктов 1С. Кто, кроме специалистов в данном вопросе, может дать независимую оценку недостатков этого программного продукта? 0