Бизнес-логика: Структура данных vs код

[metaclass]

plumqqz доставил нам очередную ссылку на ужасы обсуждения БД на хабре. Сама статья еще куда ни шло, за исключением представления constraints как мега-фичи (вроде это основа основ любой БД). В комментариях, само собой, дикий ад, трэш, угар, содомия, коровники, заборы, катаформизм хабракармы и голые бизнес-аналитекши.

Самое ужасное там - это когда структуре данных отказывают в праве считаться частью бизнес-логики, упирая на то, что "надо же абстрагироваться от хранилища".
При этом, даже если добится этого абстрагирования - то все равно структура данных будет в памяти, в виде графа объектов, будет нужен дополнительный код по интеграции этой структуры с тем, что живет в БД, и никуда мы от структуры данных не денемся. А уж про то, можно ли считать констрейнты (в т.ч. и сложные, выражаемые только в виде триггеров) частью типов данных - можно дискутировать вечно. По крайней мере, check и foreign key constraints это точно часть типа данных, в случае FK - это еще и зависимые типы, реализованные в понятном виде. В случае unique constraints - уже сложнее, но по идее, тоже зависимый тип (зависит от данных таблицы, в которой он используется).

Так вот, я считаю, что структура данных для бизнес-логики гораздо более важна, чем собственно код. Если вам скажут, что теперь операция с кодом "777029" не облагается НДС - вам всего лишь нужно добавить веточку в паттерн-матчинг. Структура программы от этого не изменится и коллегам вы билд нахрен не сломаете.
А если окажется, что для того, чтобы узнать, как обрабатывается операция, вам нужно заглянуть в настройки в СУБД - то внезапно, в гламурно-причесанной функционально-иммутабельной функции проверки условий появляется грязная монада IO, провайдеры коннектов к БД, автоматическое управление транзакциями, пул коннектов, кэши и прочая черняга и структура данных (к коей я отношу так же и сигнатуры функций) меняется весьма заметно. Альтернативный вариант - оставить функцию чистой, но добавить к ней еще параметров, передаваемых извне, проверить код коллег, записать в трекер и рассказать, что теперь без передачи в нее оккультного набора параметров функция больше не заработает.

Comments

[theiced.livejournal.com]

вот, до вас доходит же потиху. именно - ВЫКИНУТЬ К ХУЯМ всю это ненадёжную поебень.

[metaclass.livejournal.com]

А зачем ее выкидывать?
Констрейнты в виде FK,Unique и собственно структуры БД я оставлю по любому (по крайней мере, пока базы с ACID и типизированной функциональщиной не появится на горизонте).

Вот триггера и хранимые процедуры, похоже, придется оставить только для очень узких по производительности мест. Сложная логика нормальным повторно используемым образом туда не складывается, даже если SQL генерировать из нормальных языков. Разрабатывать семантику трансляции лиспа в императивные SQL-расширения разных серверов - ну его нахер, я лучше с нуля напишу.

[theiced.livejournal.com]

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

[metaclass.livejournal.com]

Не, ты что. Меня ждать отчета даже 10 секунд бесит, а ты предлагаешь минуту :)

[blackyblack.livejournal.com]

Гы. Ребе Б. ругает констрейнты, ребе А. ругает сторед проки, ребе М. использует всего по-маленьку. И все на меня псят за то, что я сказал, что форейн ключи не нужны. :)