Обсуждение:Закрытие периода (постановка)

Версия 22:07, 6 сентября 2008

Целью работы является не создание таблиц, процедур и триггеров, а ускорение работы стандартных бухгалтерских отчетов. Механизм закрытия периода -- это всего лишь средство достижения поставленной цели, причем одно из нескольких и, еще не доказано, что самое оптимальное. Рассматривая проблему в таком ракурсе, начинать надо в обратном порядке от того, который присутствует в статье, а именно:

1. Рассмотреть каждый из бухгалтерских отчетов по следующей схеме:
   1. Название отчета
   2. Предназначение отчета. Какие задачи выполняет бухгалтер с помощью данного отчета? Каким образом использует его? Какие параметры в основном использует для построения отчета? За какие периоды строится данный отчет в повседневной практике? Как часто бухгалтер пользуется данным отчетом? и т.п.
   3. Показать внешний вид окна, вид печатной формы.
   4. Разобраться с тем, какие запросы используются для извлечения данных отчета. Каким образом формируются эти запросы. Привести их.
   5. На рабочей базе данных (желательно взять несколько характерных баз) измерить время выполнения запросов для извлечения данных отчета. Определить где собственно теряется время и как следует оптимизировать запросы, чтобы повысить производительность. (Может так получиться, что запросы на извлечение сальдо по счету и не являются основной причиной задержек!)
   6. Предложить варианты ускорения запросов как с использованием механизма закрытия периода, так и с использованием новых возможностей сервера.
   7. Разработать новые алгоритмы формирования и привести примеры уже сформированных запросов.
2. Только после этого следует приступать к проработке механизма закрытия.
   1. Структура таблицы;
   2. Триггеры и хранимые процедуры;
   3. Алгоритм работы механизма.

Замечания:

• Сальдо по английски будет balance. Некрасиво получается, когда в наименовании таблицы используются и английские слова (ENTRY) и латинские (?) -- сальдо.
• "Бухгалтерское закрытие периода" -- это вполне конкретная операция, определенная в бухгалтерском учете и не имеющая ничего общего с нашим термином (см. Реформация баланса). Я бы, во избежание путаницы, вообще не использовал термин "Закрытие периода", так как по сути это никакое не закрытие. "Подсчет суммарных значений", "Подсчет итоговых значени", что-нибудь в таком роде.
• По структуре таблицы: не показаны все ее составляющие части, например, внешние ключи. Так как данная таблица является комплиментарной к AC_ENTRY, то я бы создавал все поля-ссылки без внешних ключей, т.е. просто как целочисленные поля. Таким образом мы добьемся ускорения при внесении информации, но, теоретически возможно появление неверных ссылок. Впрочем, если при закрытии полностью очищать данную таблицу, то это и не так страшно.
• "После выполнения процедуры закрытия периода на таблицу AC_ENTRY должен быть повешен универсальный триггер" -- почему именно после?
• "CAST('01.01.2008' AS DATE)" -- тут стоит подумать, имеет ли смысл жестко кодировать дату в тексте триггера. Может стоит использовать глобальные переменные сервера, генераторы? В противном случае, операция Подведения итогов сможет выполняться только в монопольном режиме, что не всегда будет возможно на больших предприятиях. Вообще, вопрос блокировки таблицы с итоговыми значениями на вопрос их построения не рассмотрен. А ведь нельзя допустить, чтобы в процессе перестроения этой таблицы кто-то смог построить отчет, так как он приведет к неверным, ошибочным результатам.
• "(NEW.debitncu > 0) OR (NEW.debitcurr > 0) OR (NEW.creditncu > 0) OR (NEW.creditcurr > 0)" -- наверное, лишняя проверка. Вставка всех нулей -- это ошибочная ситуация в программе, которая будет встречаться крайне-крайне редко, если вообще будет. И ради нее проверять каждую вставку -- это лишняя трата ресурсов.
• "IF (UPDATING AND OLD.entrydate <= CAST('01.01.2008' AS DATE) AND (OLD.debitncu <> NEW.debitncu) OR (OLD.creditncu <> NEW.creditncu) OR (OLD.debitcurr <> NEW.debitcurr) OR (OLD.creditcurr <> NEW.creditcurr))" -- почему только суммы? Измениться может все что угодно: дата, аналитика, валюта и т.п. Так что в случае апдейта, я бы всегда делал две операции 1) удаление старой даписи и 2) добавление новой.
• "В момент построения бухгалтерского отчета необходимо проверять количество дельта-записей. Если оно превысит некоторый лимит, то устанавливать флаг, по состоянию которого перестраивать таблицу AC_ENTRY_SALDO. Это можно делать каждый раз перед/после построения бухгалтерского отчета, или в период простоя Гедемина." -- тут надо расписать конкретно: а) как будет проверяться количество дельта записей; б) как они будут сворачиваться; в) в какой момент.

AndreiK 19:17, 6 September 2008 (CEST)

• "(NEW.debitncu > 0) OR (NEW.debitcurr > 0) OR (NEW.creditncu > 0) OR (NEW.creditcurr > 0)" -- наверное, лишняя проверка. Вставка всех нулей -- это ошибочная ситуация в программе, которая будет встречаться крайне-крайне редко, если вообще будет. И ради нее проверять каждую вставку -- это лишняя трата ресурсов.

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

• "В момент построения бухгалтерского отчета необходимо проверять количество дельта-записей. Если оно превысит некоторый лимит, то устанавливать флаг, по состоянию которого перестраивать таблицу AC_ENTRY_SALDO. Это можно делать каждый раз перед/после построения бухгалтерского отчета, или в период простоя Гедемина." -- тут надо расписать конкретно: а) как будет проверяться количество дельта записей; б) как они будут сворачиваться; в) в какой момент.

1. Можно сделать так, с помощью глобальной переменной(генератора) устанавливаем флаг. Далее, при подлючению к Гедымину проверяем, если кол-во подлючённых пользователей 1(только мы), то запускаем процедуру сворачивания. Можно для этого процесса запустить отдельный поток(или асинхронный запрос в FB2.5).

• "CAST('01.01.2008' AS DATE)" - генератор, как сделано в блокировке периода.
• На счёт того, что сначала надо изучить бухгалтерские отчёты. В данном случае все варианты их изменения(оптимизации) можно проводить, только когда сделано уже некоторое сворачивание сальдо в тестовую таблицу. Так что всё идёт верно.

Alexander 20:26, 6 September 2008 (CEST)

"Вот тут я не согласен - лучше обезопасить себя от ошибочных ситуаций".

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

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

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

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

AndreiK 20:57, 6 September 2008 (CEST)

Хм...запросы будем на бумажке писать без тестовых данных?

Alexander 21:07, 6 September 2008 (CEST)