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

[metaclass]

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

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

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

Comments

[falcrum.livejournal.com]

Особенно хорошо чувствуешь важность структуры БД, когда всё уже Х лет работает и поменять нет никакой возможности: просто смотришь с тоской и думаешь - э-эх, вот писал бы это я сейчас...

[maxdz.livejournal.com]

В годы моего детства, когда я ещё участвовал в написании ЕРП-подобных систем - хранение бизнес-логики в хранимых процедурах было большим "no-no", т.к. функциональность предметной области не должна размываться между кодом и БД.

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

Ограничения в БД могут быть, но могут и не быть, т.к. бизнес-логика, как правило, накладывает свои (сужающие, заложенные в структуре БД) ограничения.

[justy-tylor.livejournal.com]

Строгую границу между "что часть системы типов, а что нет" обычно хрен проведёшь, ибо для этого надобна разница между типом и не-типом, коей в природе не наблюдается. Удобно считать типом то, что пользует не более O(log размер_таблицы), а остальное относить к сессиям верификации датасета.

Про важность структуры данных большое ДА! Если данные (и их модальности) не проебали, то их можно хоть через сто лет обработать новым кодом под новые обстоятельства. А если опаньки, то криптоархеологи и вуду-ритуалы не спасут.

[lazy-flyer.livejournal.com]

Ребе, у вас снова появилось много значений слова invoice...
Безнес-логика бизнеса? Или бизнес-логика раеализации бизнес-логики?
В первом случае структуры данных этой логике пох, она на другом уровне оперирует...

[metaclass.livejournal.com]

Например, появление новой сущности в первичных документах: не особо меняет логику работы, но заметно меняет структуру БД, структуру графа объектов в памяти клиента или сервера приложений.

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

[lazy-flyer.livejournal.com]

Ребе, структура данных в бизнесе - первична. И напрямую связана с бизнес-логикой бизнеса. Код, оперирущий данными, только их перерабатывает и представляет в виде приемлемым для бизнес-логики бизнеса.
Что не означает, как вы правильно заметили, необходимости хранить логику бизнеса в структурах данных. Умело запроектированная БД - благо и нимб на голову аналитика.

[zelanton.livejournal.com]

не читал, но осуждаю скажу за entity–attribute–value model поверх реляционной БД и любая хня данных настраивается по месту, а бизнес-логика от данных реально абстрагирована и вообще она на 83% настраивается внедренцем по месту, в гламурной административной консольке.

[pascendi.livejournal.com]

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

[nivanych.livejournal.com]

У вас тут не хабр, с вами тут, почему-то, особенно не спорят...
А про структуры данных — надо сначала определить, что такое данные.
Вот например, лямбдо-исчислёниё-функция — это данные? ;-)
А то вот, замкнулись в своём SQL!
Есличо, я тут не говорю, что как будто, в этом есть что-то плохое ;-)

[metaclass.livejournal.com]

Упоминали ли разработчики оного зависимые типы и бенджамина пирса?:)

[(Anonymous)]

Ну я тут неделю писал, а потом вложил это все в структуру и получил код в 1% от прошлого. Но я не пойму почему вы так уверенны что все ПО живет 1 день и что оно (ПО) завтра не потребует давать ответы на те вопросы на которые оно даже не проектировалось.

[metaclass.livejournal.com]

Я забыл про это написать, что для начала код это тоже данные, и типы это данные и вообще все данные, просто с разным поведением:)

[fd979.livejournal.com]

есть такая серьезная контора, которая одно время запрещала программерам создавать новые таблицы, но новый функционал требовала :)

а вы тут бизнес-логика, структура даанных :)

[(Anonymous)]

Дык вопрос в императивном изложении или в декларативном. Не пойму о чем копья ломаем?

[sgalitsky.livejournal.com]

> В комментариях, само собой, дикий ад, трэш, угар, содомия, коровники, заборы, катаформизм хабракармы и голые бизнес-аналитекши.
- да унылое говно в каментах на самом деле. т.е. вот реально там например отличился не совсем мудак в споре с мускулистым совсем мудаком. похабнейшее зрелище.
какие-то отморози, называщие постгре "постгрой".
и как всегда, 100% участников этого блядского срача вообще никогда не работали с ораклями.
т.е. вот даже не с Database'ом не работали, не говоря уШ о мидлваре, соа там или бпм.

это например мода такая в говне и торфе рассуждать о незнакомых и чуждЫх вещах?

[theiced.livejournal.com]

зачем вы читаете то что пишет этот идиот?

[theiced.livejournal.com]

а ты иди пятый прогресс бар приделывай

[maxdz.livejournal.com]

Хорошая идея. Может, в следующей версии. :)

[(Anonymous)]

Это что за бред? Оксюморон какой, то. 1) Серьезная и запрещала и 2) програмистам

[theiced.livejournal.com]

а сортировочку ещё веселее сделаешь, макака колхозная?

[maxdz.livejournal.com]

Ты всё перепутала, макака колхозная - я же оранжевый бандеровец.

А сортировочка и так весёлая, вроде. :)

[hazardouskadavr.livejournal.com]

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

[theiced.livejournal.com]

больше ада!

[zamotivator.livejournal.com]

Потому что он умный.

[hazardouskadavr.livejournal.com]

жырно