![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Опердень и паттерн-матчинг.
А поимею-ка я вам мозг классической задачкой из любой опердени.
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).
И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчетакоторый ложится на стол Президенту РБ, т.е. к примеру "все проводки с типом операции 126 относятся на статью затрат "Цех забоя и переработки свинины", за исключением проводок со счета 91, который относится на статью затрат "Цех забоя и переработки лошадей"". В таких правилах обычно проверяется где-то 5-10 условий на значения полей записи операции, самих правил может быть порядка сотни штук. И правила могут меняться, например в 2008 году переработка лошадей и свиней делилась на две статьи, а в 2009 министерство статистики решило, что достаточно одной статьи "забой любого скота", но обязательно детализированной по фазам луны.
И вот как бы вы такое решали?
Анализ этого дела в коде выглядит как паттерн-матчинг, реализованный вручную. Но в код это пихать как бэ нехорошо - потому что при изменениях правил придется менять код. А если хранить правила в таблице, получается что мы впадаем в грех реализации собственного языка правил и его обработки.
PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).
И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчета
И вот как бы вы такое решали?
Анализ этого дела в коде выглядит как паттерн-матчинг, реализованный вручную. Но в код это пихать как бэ нехорошо - потому что при изменениях правил придется менять код. А если хранить правила в таблице, получается что мы впадаем в грех реализации собственного языка правил и его обработки.
PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".
no subject
я, конечно, в вашей опердени ничего не понимаю, но весь веб так живет. поправил файлик - поправилась логика.
ту же схему можно выставить реплом в порт, и заливать процедуру на горячую.
no subject
Так что даже с файликами - придется привязывать правила к дате операции или дате в параметрах фильтра. Еще печальнее - это если отчет за период пересекающий дату изменения, в таком случае, вообще хорошо бы показывать два отчета.
no subject
С файликами проще. Тупо первое что в голову приходит: не затирать старый, а класть его в выбранный каталог с именем составленным из даты начала применения. А при обработке по диапазону времени выбирать нужную версию или несколько, если на стык попали и юзать.
По крайней мере с перезаливкой SQL процедур версионность так просто не слепишь.
no subject
обработчик_говна_v2.scm
...
к энтитям которые обрабатываются привязываем версию данного обработчика. при создании новой энтити - тупо берём последнюю. не вижу проблем.