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

[metaclass]

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

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

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

Comments

[vp.livejournal.com]

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

[theiced.livejournal.com]

за использование хранимых говнопроцедур - вон из пофессии.

[vp.livejournal.com]

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

Да, и со всякими разными монгаДБ целостность данных мы тоже выбрасываем? :)

[theiced.livejournal.com]

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

[tzirechnoy.livejournal.com]

Да ладно тебе, какой локин. Пишы их не перле -- и смигрируешь хоть куда.

[vp.livejournal.com]

Ребе, я вас не о фаерберде спрашиваю. А о ссылочной ка кбы целостности.
Мы будем этот закат солнца делать вручную?
Только не говорите. что если мы положим магическую базу магические объекты, на этом работа закончится. Я еще раз скажу всеми нелюбимое изречение: это все хорошо только для ограниченного круга ну очень простых задач.

[theiced.livejournal.com]

ссылочную целостность может спокойно обеспечить клиентская либа же.

[vp.livejournal.com]

поперхнулся. Ребе, что вы такое говорите? Мы об одном и том же вообще?

[metaclass.livejournal.com]

Но мы же не хотим сами делать то, что умеет СУБД :)

[vp.livejournal.com]

Ну вот мы подошли к главному, к расстановке точек над и. И что является говноедством :)

[theiced.livejournal.com]

говноедством является использование кода-в-базе! ещё раз - у вас вендор лок-ин на файрбёрд - я ваше мнение по этому конкретному вопросу ставлю на уровень мнения максдз например.

[vp.livejournal.com]

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

[9zloy.livejournal.com]

тут я за айседа. Нахер код в базе (Хотя я никогда не был настоящим программером и мое мнение можно не учитывать)

[theiced.livejournal.com]

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

[vp.livejournal.com]

То есть мы придумаем на коленке механизм транзакций, потом придумаем механизм ссылочной целостности?

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

[metaclass.livejournal.com]

Какие ORM, какие триггеры?:)
Мы за внешние ключи все еще говорим?:)

[sgalitsky.livejournal.com]

ну и идите себе, что возмущаетесь-то?

[theiced.livejournal.com]

Так я то их не пишу и не использую, в жопу ебаццо тоже не тянет как то.

[sgalitsky.livejournal.com]

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

[theiced.livejournal.com]

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

[sgalitsky.livejournal.com]

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

[theiced.livejournal.com]

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

[sgalitsky.livejournal.com]

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

[sgalitsky.livejournal.com]

вообще, интересно, как подобные вам синюшные "надмозги" бредят рабочим материалом вне работы.
вы что, по начальственному страпону дома тоскуете, ась?

[dennab.livejournal.com]

Так данных жеж, не кода и не определений таблиц. В таком случае, правда, скрипт можно и ручками нопейсать или использовать чё-нить типа СКЛ-дампа (пг_думп) и не платить много-много денег.

Да и задача мигрировать что угодно куда угодно вообще исключительная. Иметь интерфейсы к чему угодно - да, довольно часто. (НЕНАВИЖУ ИБМ! "Наш продукт работает только с DB2 v9.7 fp5" ааааааааа! и одмины идут к закащегу ипаццо с апдейтами)