Бухгалтерские проводки как функция, а не данные

У нас документы хранятся отдельно от проводок. Как уже упоминалось в этом блоге, проводки (т.е. записи в таблицы ac_entry и ac_record) формируются алгоритмами типовых проводок. В результате получаем две огромные таблицы большая часть информации в которых дублирует gd_document и данные из соответствующих документов.

Если вместо формирования VBScript-а типовой проводки формировать код selectable процедуры, которая на основании данных документов сформирует список проводок, то:

1. Избавляемся от таблиц ac_entry и ac_record.
2. Избавляемся от таблицы gd_document (на вскидку, три указанные таблицы с индексами занимают не менее четверти объема любой базы данных).
3. Избавляемся от ограничения на количество аналитических признаков. Так как проводки являются просто отображением таблицы с документами, то любое поле этой таблицы сразу становится аналитическим признаком. Более того, поле ссылка? Тогда каждое поле указываемой таблицы может быть аналитикой и так до бесконечности. Журнал ордер по продажам с группировкой не по самим клиентам, а по областям/районам можно будет построить всего за несколько кликов мышкой.
4. Избавляемся от системы количественных показателей в проводках. При необходимости вести учет одновременно в нескольких единицах измерения следует определить функцию пересчета (отображения) основной единицы в дополнительные.
5. Избавляемся от проблемы рассинхронизации данных документов и соответствующих им проводок. Никаких больше "перепровести проводки".
6. Ускоряем запись и изменение документов.
7. Избавляемся от бизнес-объектов типа Проводка, которые бизнес-объектами в полном смысле этого слова не являются.
8. Возможно, упрощается репликация данных.

Придется переделать систему бухгалтерских остатков в общую систему обновляемых агрегатных показателей по произвольным полям и таблицам (функциональность OLAP).