![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Опердень и паттерн-матчинг.
А поимею-ка я вам мозг классической задачкой из любой опердени.
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).
И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчетакоторый ложится на стол Президенту РБ, т.е. к примеру "все проводки с типом операции 126 относятся на статью затрат "Цех забоя и переработки свинины", за исключением проводок со счета 91, который относится на статью затрат "Цех забоя и переработки лошадей"". В таких правилах обычно проверяется где-то 5-10 условий на значения полей записи операции, самих правил может быть порядка сотни штук. И правила могут меняться, например в 2008 году переработка лошадей и свиней делилась на две статьи, а в 2009 министерство статистики решило, что достаточно одной статьи "забой любого скота", но обязательно детализированной по фазам луны.
И вот как бы вы такое решали?
Анализ этого дела в коде выглядит как паттерн-матчинг, реализованный вручную. Но в код это пихать как бэ нехорошо - потому что при изменениях правил придется менять код. А если хранить правила в таблице, получается что мы впадаем в грех реализации собственного языка правил и его обработки.
PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).
И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчета
И вот как бы вы такое решали?
Анализ этого дела в коде выглядит как паттерн-матчинг, реализованный вручную. Но в код это пихать как бэ нехорошо - потому что при изменениях правил придется менять код. А если хранить правила в таблице, получается что мы впадаем в грех реализации собственного языка правил и его обработки.
PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".
no subject
As far as I understood the problem, MDX is overkill for it. We have an amount of fields and some restrictions (to say, queries) applied on resultsets. There is no multidimensional data at all and using such tools as DRolls will dramatically slow the development down.
And, increase the cost, as far.