Обсуждение:Закрытие периода (постановка) - История изменений

SYSDBA в 16:37, 27 сентября 2008

2008-09-27T16:37:22Z

Alexander в 19:07, 6 сентября 2008

2008-09-06T19:07:40Z

SYSDBA в 18:58, 6 сентября 2008

2008-09-06T18:58:55Z

SYSDBA в 18:57, 6 сентября 2008

2008-09-06T18:57:47Z

SYSDBA в 18:55, 6 сентября 2008

2008-09-06T18:55:23Z

Alexander в 18:36, 6 сентября 2008

2008-09-06T18:36:29Z

Alexander в 18:31, 6 сентября 2008

2008-09-06T18:31:54Z

Alexander в 18:26, 6 сентября 2008

2008-09-06T18:26:52Z

SYSDBA в 17:17, 6 сентября 2008

2008-09-06T17:17:05Z

Новая страница

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

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

Замечания:

* Сальдо по английски будет 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. Это можно делать каждый раз перед/после построения бухгалтерского отчета, или в период простоя Гедемина." -- тут надо расписать конкретно: а) как будет проверяться количество дельта записей; б) как они будут сворачиваться; в) в какой момент.

[[Участник:SYSDBA|AndreiK]] 19:17, 6 September 2008 (CEST)

← Предыдущая		Версия 16:37, 27 сентября 2008
Строка 53:		Строка 53:

	[[Участник:Alexander\|Alexander]] 21:07, 6 September 2008 (CEST)		[[Участник:Alexander\|Alexander]] 21:07, 6 September 2008 (CEST)
		+
		+	Я бы не создавал внешние ссылки по полям в таблице с сальдовыми значениями. Это производная таблица и такой ситуации, что
		+	будет запись в балансе, но ее не будет в списке проводок -- просто не может быть. Соответственно, и нарушиться целостность
		+	данных не может. Каждый внешний ключ -- это индекс, который обновляется при любом изменении таблицы.
		+
		+	[[Участник:SYSDBA\|AndreiK]] 18:37, 27 September 2008 (CEST)

← Предыдущая		Версия 19:07, 6 сентября 2008
Строка 49:		Строка 49:

	[[Участник:SYSDBA\|AndreiK]] 20:57, 6 September 2008 (CEST)		[[Участник:SYSDBA\|AndreiK]] 20:57, 6 September 2008 (CEST)
		+
		+	Хм...запросы будем на бумажке писать без тестовых данных?
		+
		+	[[Участник:Alexander\|Alexander]] 21:07, 6 September 2008 (CEST)

@@ Строка 40: / Строка 40: @@
 "Вот тут я не согласен - лучше обезопасить себя от ошибочных ситуаций".
-Это не ошибка. Пустая запись не начто не повлияет. Из нескольких миллионов, вдруг, просочится одна, а скорее всего и не одной... так зачем проверять миллионы?
+Это не ошибка. Пустая запись ни на что не повлияет. Из нескольких миллионов, вдруг, просочится одна, а скорее всего и не одной... так зачем проверять миллионы?
 "В данном случае все варианты их изменения(оптимизации) можно проводить, только когда сделано уже некоторое сворачивание сальдо в тестовую таблицу"

← Предыдущая		Версия 18:57, 6 сентября 2008
Строка 41:		Строка 41:

	Это не ошибка. Пустая запись не начто не повлияет. Из нескольких миллионов, вдруг, просочится одна, а скорее всего и не одной... так зачем проверять миллионы?		Это не ошибка. Пустая запись не начто не повлияет. Из нескольких миллионов, вдруг, просочится одна, а скорее всего и не одной... так зачем проверять миллионы?
		+
		+	"В данном случае все варианты их изменения(оптимизации) можно проводить, только когда сделано уже некоторое сворачивание сальдо в тестовую таблицу"
		+
		+	Сначала изучить, а затем предлагать. Не изучив как это работает сейчас, не понятно оптимален ли предложенный вариант с точки зрения реализации.
		+
		+	Вообще, на серьезных фирмах действует правило "трех опций". Это значит, что для любой проблемы сначала предлагается три разных варианта решения. Они рассматриваются, из них выбирается самый лучший, и только потом он реализуется.
		+
		+	[[Участник:SYSDBA\|AndreiK]] 20:57, 6 September 2008 (CEST)

← Предыдущая		Версия 18:55, 6 сентября 2008
Строка 37:		Строка 37:

	[[Участник:Alexander\|Alexander]] 20:26, 6 September 2008 (CEST)		[[Участник:Alexander\|Alexander]] 20:26, 6 September 2008 (CEST)
		+
		+	"Вот тут я не согласен - лучше обезопасить себя от ошибочных ситуаций".
		+
		+	Это не ошибка. Пустая запись не начто не повлияет. Из нескольких миллионов, вдруг, просочится одна, а скорее всего и не одной... так зачем проверять миллионы?

@@ Строка 33: / Строка 33: @@
 #Можно сделать так, с помощью глобальной переменной(генератора) устанавливаем флаг. Далее, при подлючению к Гедымину проверяем, если кол-во подлючённых пользователей 1(только мы), то запускаем процедуру сворачивания. Можно для этого процесса запустить отдельный поток(или асинхронный запрос в FB2.5).
 * На счёт того, что сначала надо изучить бухгалтерские отчёты. В данном случае все варианты их изменения(оптимизации) можно проводить, только когда сделано уже некоторое сворачивание сальдо в тестовую таблицу. Так что всё идёт верно.
 [[Участник:Alexander|Alexander]] 20:26, 6 September 2008 (CEST)

← Предыдущая		Версия 18:26, 6 сентября 2008
Строка 1:		Строка 1:
−
	Целью работы является не создание таблиц, процедур и триггеров, а ускорение работы стандартных бухгалтерских отчетов. Механизм закрытия периода -- это всего лишь средство достижения поставленной цели, причем одно из нескольких и, еще не доказано, что самое оптимальное. Рассматривая проблему в таком ракурсе, начинать надо в обратном порядке от того, который присутствует в статье, а именно:		Целью работы является не создание таблиц, процедур и триггеров, а ускорение работы стандартных бухгалтерских отчетов. Механизм закрытия периода -- это всего лишь средство достижения поставленной цели, причем одно из нескольких и, еще не доказано, что самое оптимальное. Рассматривая проблему в таком ракурсе, начинать надо в обратном порядке от того, который присутствует в статье, а именно:

Строка 27:		Строка 26:

	[[Участник:SYSDBA\|AndreiK]] 19:17, 6 September 2008 (CEST)		[[Участник:SYSDBA\|AndreiK]] 19:17, 6 September 2008 (CEST)
		+
		+
		+	* "(NEW.debitncu > 0) OR (NEW.debitcurr > 0) OR (NEW.creditncu > 0) OR (NEW.creditcurr > 0)" -- наверное, лишняя проверка. Вставка всех нулей -- это ошибочная ситуация в программе, которая будет встречаться крайне-крайне редко, если вообще будет. И ради нее проверять каждую вставку -- это лишняя трата ресурсов.
		+	#Вот тут я не согласен - лучше обезопасить себя от ошибочных ситуаций, тем более что трата ресурсов в данном случае мизерная и несоизмерима с другими действиями(например вставкой записи).
		+	* "В момент построения бухгалтерского отчета необходимо проверять количество дельта-записей. Если оно превысит некоторый лимит, то устанавливать флаг, по состоянию которого перестраивать таблицу AC_ENTRY_SALDO. Это можно делать каждый раз перед/после построения бухгалтерского отчета, или в период простоя Гедемина." -- тут надо расписать конкретно: а) как будет проверяться количество дельта записей; б) как они будут сворачиваться; в) в какой момент.
		+	#Можно сделать так, с помощью глобальной переменной(генератора) устанавливаем флаг. Далее, при подлючению к Гедымину проверяем, если кол-во подлючённых пользователей 1(только мы), то запускаем процедуру сворачивания. Можно для этого процесса запустить отдельный поток(или асинхронный запрос в FB2.5).
		+
		+	[[Участник:Alexander\|Alexander]] 20:26, 6 September 2008 (CEST)