Факт – вещь упрямая



Posted by Владимир Секретёв, Клуб Любителей Бухгалтерского Учета on December 26, 1998 at 12:20:21:

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

Механизм фактов, конечно, достаточно удобно решает многие проблемы «Финансов», такие как различные анализы, показ проводок в сетевой версии, генерацию многострочных и вообще документов. Но наряду с преимуществами наличествуют и недостатки. К сожалению, недостатки этой структуры данных, с моей точки зрения, «перевешивают» достоинства. В этой небольшой заметке я постараюсь сравнить механизм фактов с другими подходами в программировании «Финансов» - использовании форм-историй, экстрапараметов и EXTRD.DAT.

Начнем с притчи во языцах – быстродействия. Факты, по мере их порождения, размещаются в памяти последовательно и образуют структуру называемую лентой фактов. Нет другой возможности найти искомый факт или группу фактов, как только путем последовательного просмотра ленты и сравнения с образцом. Причем заранее не известно, сколько подходящих по образцу фактов находится в ленте, поэтому приходится просматривать ее от начала и до конца. Так поступают операторы SEARCH, SELECT, TOTAL, ERASE. Операторы NERASE, NEWS и RANGE слегка оптимизируют этот процесс, не решая, впрочем, проблему кардинально. Таким образом, лента фактов является УСТРОЙСТВОМ ПОСЛЕДОВАТЕЛЬНОГО ДОСТУПА, и она всегда будет проигрывать по быстродействию индексированным структурам - экстрапараметрам и EXTRD.DAT (если бы, конечно, EXTRD.DAT располагался на сравнимом по скорости доступа устройстве) так, как накопитель на магнитной ленте проигрывает «винчестеру».

Второе - это требования по памяти. Берусь утверждать, что удерживать факты в памяти компьютера не рационально. Факт есть вещь свершившаяся, изменению не подлежащая. То есть отдельно взятый факт не меняется во времени. В этом смысле он мертв. Он не динамичен. Зачем не динамическую по сути своей структуру хранить в ОЗУ, да еще в двойном экземпляре? Я не рассматриваю тут случай, когда факты используются для описания неких динамических процессов, если несколько последовательных фактов отражают изменения одного показателя. Это уж вообще не годный метод их использования. Добавим еще «прошлогодние» факты, загрузившиеся в наше бедное ОЗУ из файла FACTS.B, и, через пару-тройку лет, вы придете к кризису недостатка ресурсов. А хранить справочники и иметь быстрый и удобный доступ к архивам прошлогодних документов надо. Итак, вывод - фактам место на диске! То есть вместо них нужно использовать EXTRD.DAT.

Третья ипостась фактов – анализ. И здесь факты дают слабину. Ну, во-первых, что является первоисточником данных для анализа? Ответ прост – журнал операций. Обратите внимание – журнал – это ЛЕНТА операций. Мы берем ЛЕНТУ операций, ЧАСТЬ ее данных копируем в ЛЕНТУ фактов, этим загружаем ОЗУ (х2) и тратим на это время сервера. Все это - нонсенс с точки зрения рациональности. Предвижу возражения примерно такого плана – «в фактах подготавливаются данные для последующего анализа, его проводить проще и аналитические формы работают быстро». Да, возможно это так. Но ценой падения производительности сервера при пересчете баланса и повышенными требованиями к ОЗУ. Есть еще одна цена, которую регулярно платят фактам трудолюбивые настройщики «Финансов». В том случае, если первоначально придуманная структура некоего факта оказывается либо не удовлетворительной либо не полной, то им (настройщикам) приходится вносить исправления в несколько или даже во много файлов-коэффициентов, которые этот факт порождают. Потом следует перезагрузка сервера, его падение из-за какой-нибудь дурацкой ошибки и, после удачного старта доработка аналитической формы. Куда как изящнее анализировать что-то с помощью только формы. Заводишь форму на клиенте, отлаживаешь ее на полном наборе данных, никаких рестартов, в любой момент вносишь какие угодно модификации. Хорошо подходят для целей анализа формы-истории. Их только немного нужно довести до ума (Аркадий!). Чтобы в разделе PROLOG можно было использовать функции типа [ba], чтобы они нормально реагировали на ОП, чтобы сервер не шуровал весь год, если ОП – один месяц, чтобы после выполнения формы-истории сервер не сообщал об изменении вычислительного состояния. А сейчас, с появлением функции [jf] доступ ко всему содержимому операции упрощен до предела – знаешь уникальный код, бери и анализируй операцию. Тут уж и без форм историй обойтись довольно легко.

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



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