Опердень и паттерн-матчинг.

[metaclass]

А поимею-ка я вам мозг классической задачкой из любой опердени.
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).

И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчета который ложится на стол Президенту РБ, т.е. к примеру "все проводки с типом операции 126 относятся на статью затрат "Цех забоя и переработки свинины", за исключением проводок со счета 91, который относится на статью затрат "Цех забоя и переработки лошадей"". В таких правилах обычно проверяется где-то 5-10 условий на значения полей записи операции, самих правил может быть порядка сотни штук. И правила могут меняться, например в 2008 году переработка лошадей и свиней делилась на две статьи, а в 2009 министерство статистики решило, что достаточно одной статьи "забой любого скота", но обязательно детализированной по фазам луны.

И вот как бы вы такое решали?

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

PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".

Comments

[theiced.livejournal.com]

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

[tretiy3.livejournal.com]

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

[metaclass.livejournal.com]

Логика версионная. Мы должны уметь посмотреть старый отчет(за 2008 год к примеру) в том виде, в котором он был тогда. А новые - по новому.
Так что даже с файликами - придется привязывать правила к дате операции или дате в параметрах фильтра. Еще печальнее - это если отчет за период пересекающий дату изменения, в таком случае, вообще хорошо бы показывать два отчета.

[graynm.livejournal.com]

+1
С файликами проще. Тупо первое что в голову приходит: не затирать старый, а класть его в выбранный каталог с именем составленным из даты начала применения. А при обработке по диапазону времени выбирать нужную версию или несколько, если на стык попали и юзать.

По крайней мере с перезаливкой SQL процедур версионность так просто не слепишь.

[theiced.livejournal.com]

обработчик_говна_v1.scm
обработчик_говна_v2.scm
...

к энтитям которые обрабатываются привязываем версию данного обработчика. при создании новой энтити - тупо берём последнюю. не вижу проблем.