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

[metaclass]

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

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

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

Comments

[theiced.livejournal.com]

Foo.where(:bar => 'bee').update_all(:huj => 'хуй')

[vp.livejournal.com]

Я не про апдейт, я про апдейт схемы базы.
У вас была версия 1.1, вы апдейтите изделие на 1.8
Как ваш чудо орм автоматически обновит ту базу, на которой работает?
в 1.8 у вас удалили половину полей, который были в 1.1 и создали другую половину.

[theiced.livejournal.com]

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

[metaclass.livejournal.com]

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

[vp.livejournal.com]

Ну дык для того, чтобы сделать апдейт схемы, необходимо эту схему представлять. И необходимо понимать, на каком состоянии у тебя находится обновляемая система к твоей текущей версии, до которой ты собираешься ее догнать.
Как ты это делаешь без понимания того, как устроена база? (мы только что постулировали, что только так и нужно и нам пофиг что там)

[metaclass.livejournal.com]

В рубях ВСЯ схема базы делается в виде классов и миграций, т.е. вообще вся. И в базе есть таблица, аналогичная нашей, для трекинга версий
Т.е. оно банально один раз запускаешь rake db:migrate и апдейты на базу накатывается.

[theiced.livejournal.com]

оно везде так. даже в жабе ;]

[metaclass.livejournal.com]

На первой странице гугла по "java orm migrations" выводит только одну ссылку на эту тему, и та - порт activerecord :)

[metaclass.livejournal.com]

http://stackoverflow.com/questions/2969827/does-there-exist-a-tool-for-db-schema-migration-where-schema-are-specified-using

[metaclass.livejournal.com]

Что ты несешь, мы же обсуждаем апдейты данных, а не метаданных.

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

Т.е. вообще говоря, все эти ORM и прочая чернь - это способ упростить себе работу с базой, не вникая в ее тонкости. При этом приходится выкидывать все, что СУБД умеет делать сама, т.к. другие сервера это делают по другому.

[theiced.livejournal.com]

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

[metaclass.livejournal.com]

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

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

[theiced.livejournal.com]

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

[metaclass.livejournal.com]

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

[blackyblack.livejournal.com]

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

[vp.livejournal.com]

То есть как обычно есть золотая пуля и на самом деле вопрос выеденого яйца не стоит. Ок.

[metaclass.livejournal.com]

Я более чем уверен, что если мы возьмем эту "золотую пулю", мы через неделю в накопаем в ней чернейших багов, а через месяц упремся в то, что "ДА ЭТОГО ЖЕ НИКТО ТАК НЕ ДЕЛАЕТ".

[vp.livejournal.com]

Нет, мы упремся в то, что в нашей реальности этим можно пользоваться, но только допилив 50% вручную.

[theiced.livejournal.com]

бредите ;]

[metaclass.livejournal.com]

Серьезно. У меня затыки вида "нужно идти на поклон к автору или чинить самому и потом поддерживать свои патчи поверх апстрима" возникают раз в неделю.

[(Anonymous)]

Серебряная.