О стиле программирования и использовании фактов



Posted by Васеленко Сергей, Фирма КАРДИНАЛ on December 27, 1998 at 13:02:35:

In Reply to: Факт – вещь упрямая posted by Владимир Секретёв, Клуб Любителей Бухгалтерского Учета on December 26, 1998 at 12:20:21:

Хочу поделиться своими соображениями по поводу написания настроек.

Мы используем все механизмы ФБП кроме форм-историй.

Т.е. параметры, экстра-параметры, факты, дисковую базу данных и параметр %.

1. Параметры

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

Это соответствует их спецификации в ФБП и логике работы системы.

Примеры: льготы сотрудников, оклад, ставки износа ОС, режимы работы системы.

2. Экстра-параметры

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

Примеры: остатки товаров по себестоимости, в количестве по предприятию и на складе, цены товаров, налогооблагаемые базы для зарплаты, начисленный износ ОС.

Для определения значений таких параметров используется [get ...] и все.

3. Факты

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

Примеры: построение накладных, счетов-фактур, анализ счета.

Простая архитектура обращения и использования:
:NEXT_FACT
search ....
! [success]=0
goto END_FACT
!
... Вывод значений
goto NEXT_FACT
------------------------------------------------

В файлах-коэффициентах используется только конструкция fact. В системе 8 типов фактов.

В формах используется search, news, select, sort

Операторы erase, nerase, total не использую и считаю вредными.

По поводу использования памяти и total см.ниже.

------------------------------------------------
Очень мощный механизм построения отчетов - однопроходное сканирование ленты фактов и накопление значений в параметре %.

***********************************
#_41
NO=[set %,[n1 #]+'|D',0] Обнуление значений перед накоплением
#
***********************************
:NEXT_FACT
search ...,?D,...
! [success]=0
goto END_FACT
!
...Фильтр на выполнение условий накопления
NO=[plus %,N1+'|D',D] Накопление значений
goto NEXT_FACT
***********************************
:END_FACT
#_41
D =[get %,[n1 #]+'|D'] Чтение значений
... Вывод
#
***********************************

Такая конструкция позволяет сканировать ленту фактов и за один проход (100000 фактов в секунду) генерировать любые значения на определенную дату или за период.

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

По поводу экономии памяти.
Результаты теста системы я приведу в отдельном сообщении.

Идея такая - факты используются только для построения отчетов. В файлах-коэффициентах факты только генерируются.

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

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

Но это лучше, чем вообще отрезать данные за предыдущий период.

Расчет памяти по фактам следует вести за 5 месяцев (3 предыдущего квартала+ 2текущего).
После этого предыдущий период закрывается (регистрируется операция типа "Период закрыт" и факты не генерируются).

К примеру, система со 10 000 операциями прихода и 90 000 продажи за год с фактами требует 95М, а без фактов всего 15М. Все с учетом режима dual. Время сбивки на P133 c 32М памяти соответственно 10 и 7 минут.

И здесь еще есть экономия. См. сообщение о тесте.

Факты с прошлого года в нашей системе вообще не нужны. Файл facts.e вообще удаляется и все.

Я считаю, это соотвествует методике ведения бух.учета. Начался новый период, есть начальные остатки и больше ничего не нужно. Если что-то надо с прошлого, туда, пожалуйста, и обращайтесь.

Факты ta не используются. Вместо них собственные факты Entry.
Основные причины замены - один факт вместо 4 ta, дополнительная информация в факте о номерах документа и аналитике дебета и кредита проводки.


4. Дисковая база данных.

До последнего времени использовалась исключительно для хранения статических параметров, типа реквизитов предприятий.

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

Факты содержат набор значений, уплотняются в памяти, производится контроль типов.

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

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

Выигрыш в скорости расчета должен по идее быть. Но я сомневаюсь в производительности системы в целом.

Идеология ФБП: журнал - - предварительные итоги - - отчеты.

Отчеты оперируют встроенными функциями, типа [ea],[od],[op], параметрами, фактами и т.д.
Для каждого случая есть свои механизмы.

И все это заменять на [sed],[ged], заботиться о динамической пересбивке и т.д. я не вижу.

Не хочу обидеть Алексея Данилова. Наоборот то, что он это реализовал и это работает, это класс.
Но мне кажется, что это могут позволить себе супер-профессионалы и для решения конкретных задач.

По собственному опыту, такие системы сложны в отладке разработчиком и доработке конечным пользователем.

-----------------------------
В последнее время дисковая база данных используется для решения следующих задач:
В момент построения отчета, вычисляются какие-либо данные.
Эти данные записываются в базу и устанавливается сигнатура для подготовленных данных.

При повторном простроении отчетов, если сигнатура не изменилась (баланс не пересчитан, период не изменился и т.д. для каждого конкретного случая), то эти данные повторно не пересчитываются, а берутся уже готовые.

Такой механизм у нас называется кешированием.

Основное использование кеширования - хранение структуры индексов документов поставщиков и покупателей.
-----------------------------

5. Параметр %

Механизм используется для получения значений в отчетах при сканировании ленты фактов.
Пример использования см.выше.

Использование параметров занимает определенный объем памяти. Освобождается эта память только при смене контекста сервером (в UltraF вообще не освобождается).

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

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


6. Формы-истории.

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

Использую все же формы для отслеживания значений параметров и т.д. после каждой операции при отладке форм.

Резюме.

Наши настройки используют концепции и спецификации механизмов, рекомендованные разработчиком - фирмой "Хакерс Дизайн".

Исключения: ta-факты и формы-истории (для пользователей).

Системы просты в доработке, обслуживании.

Результаты тестирования системы на 100 000 операций будут приведены в отдельном сообщении.


Пpишедшие ответы: