Опердень и паттерн-матчинг.
Nov. 18th, 2009 05:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassА поимею-ка я вам мозг классической задачкой из любой опердени.
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).
И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчетакоторый ложится на стол Президенту РБ, т.е. к примеру "все проводки с типом операции 126 относятся на статью затрат "Цех забоя и переработки свинины", за исключением проводок со счета 91, который относится на статью затрат "Цех забоя и переработки лошадей"". В таких правилах обычно проверяется где-то 5-10 условий на значения полей записи операции, самих правил может быть порядка сотни штук. И правила могут меняться, например в 2008 году переработка лошадей и свиней делилась на две статьи, а в 2009 министерство статистики решило, что достаточно одной статьи "забой любого скота", но обязательно детализированной по фазам луны.
И вот как бы вы такое решали?
Анализ этого дела в коде выглядит как паттерн-матчинг, реализованный вручную. Но в код это пихать как бэ нехорошо - потому что при изменениях правил придется менять код. А если хранить правила в таблице, получается что мы впадаем в грех реализации собственного языка правил и его обработки.
PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).
И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчета
И вот как бы вы такое решали?
Анализ этого дела в коде выглядит как паттерн-матчинг, реализованный вручную. Но в код это пихать как бэ нехорошо - потому что при изменениях правил придется менять код. А если хранить правила в таблице, получается что мы впадаем в грех реализации собственного языка правил и его обработки.
PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-11-18 07:41 pm (UTC)А чтобы оптимально и на уровне базы то просто таблица правил выходного отчёта, в которой для каждой статьи выходного отчёта запись с источником и условиями, делов то :)
no subject
Date: 2009-11-18 09:49 pm (UTC)ну на кой хрен там xml и уродливо-ублюдочный xslt если есть кошерная схема например.
no subject
Date: 2009-11-19 08:53 am (UTC)Это именно то, что кошерно и по стандартам.