Бизнес-логика: Структура данных vs код
Oct. 19th, 2012 10:23 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclass![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
plumqqz доставил нам очередную ссылку на ужасы обсуждения БД на хабре. Сама статья еще куда ни шло, за исключением представления constraints как мега-фичи (вроде это основа основ любой БД). В комментариях, само собой, дикий ад, трэш, угар, содомия, коровники, заборы, катаформизм хабракармы и голые бизнес-аналитекши. Самое ужасное там - это когда структуре данных отказывают в праве считаться частью бизнес-логики, упирая на то, что "надо же абстрагироваться от хранилища".
При этом, даже если добится этого абстрагирования - то все равно структура данных будет в памяти, в виде графа объектов, будет нужен дополнительный код по интеграции этой структуры с тем, что живет в БД, и никуда мы от структуры данных не денемся. А уж про то, можно ли считать констрейнты (в т.ч. и сложные, выражаемые только в виде триггеров) частью типов данных - можно дискутировать вечно. По крайней мере, check и foreign key constraints это точно часть типа данных, в случае FK - это еще и зависимые типы, реализованные в понятном виде. В случае unique constraints - уже сложнее, но по идее, тоже зависимый тип (зависит от данных таблицы, в которой он используется).
Так вот, я считаю, что структура данных для бизнес-логики гораздо более важна, чем собственно код. Если вам скажут, что теперь операция с кодом "777029" не облагается НДС - вам всего лишь нужно добавить веточку в паттерн-матчинг. Структура программы от этого не изменится и коллегам вы билд нахрен не сломаете.
А если окажется, что для того, чтобы узнать, как обрабатывается операция, вам нужно заглянуть в настройки в СУБД - то внезапно, в гламурно-причесанной функционально-иммутабельной функции проверки условий появляется грязная монада IO, провайдеры коннектов к БД, автоматическое управление транзакциями, пул коннектов, кэши и прочая черняга и структура данных (к коей я отношу так же и сигнатуры функций) меняется весьма заметно. Альтернативный вариант - оставить функцию чистой, но добавить к ней еще параметров, передаваемых извне, проверить код коллег, записать в трекер и рассказать, что теперь без передачи в нее оккультного набора параметров функция больше не заработает.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-20 09:30 pm (UTC)no subject
Date: 2012-10-20 09:35 pm (UTC)no subject
Date: 2012-10-20 09:38 pm (UTC)У вас была версия 1.1, вы апдейтите изделие на 1.8
Как ваш чудо орм автоматически обновит ту базу, на которой работает?
в 1.8 у вас удалили половину полей, который были в 1.1 и создали другую половину.
no subject
Date: 2012-10-20 09:41 pm (UTC)no subject
Date: 2012-10-20 09:49 pm (UTC)А схема и прочее для ормов генерируется из модели, т.к. полное описание предметки в виде модели слишком сложное, чтобы его запихивать в любой частный язык программирования (за исключением разного рода лиспов, разве что)
no subject
Date: 2012-10-21 07:38 am (UTC)Как ты это делаешь без понимания того, как устроена база? (мы только что постулировали, что только так и нужно и нам пофиг что там)
no subject
Date: 2012-10-21 08:08 am (UTC)Т.е. оно банально один раз запускаешь rake db:migrate и апдейты на базу накатывается.
no subject
Date: 2012-10-21 08:54 am (UTC)no subject
Date: 2012-10-21 09:05 am (UTC)no subject
Date: 2012-10-21 09:05 am (UTC)no subject
Date: 2012-10-20 09:45 pm (UTC)Для метаданных есть миграции в рубевой activerecord, а поскольку в базе логику и вообще хоть что-то осмысленное делать у них не принято, то функций типа "добавить/удалить таблицу" и "добавить/удалить поле" более чем достаточно :)
Т.е. вообще говоря, все эти ORM и прочая чернь - это способ упростить себе работу с базой, не вникая в ее тонкости. При этом приходится выкидывать все, что СУБД умеет делать сама, т.к. другие сервера это делают по другому.
no subject
Date: 2012-10-20 09:50 pm (UTC)no subject
Date: 2012-10-20 10:07 pm (UTC)Констрейнты в виде FK,Unique и собственно структуры БД я оставлю по любому (по крайней мере, пока базы с ACID и типизированной функциональщиной не появится на горизонте).
Вот триггера и хранимые процедуры, похоже, придется оставить только для очень узких по производительности мест. Сложная логика нормальным повторно используемым образом туда не складывается, даже если SQL генерировать из нормальных языков. Разрабатывать семантику трансляции лиспа в императивные SQL-расширения разных серверов - ну его нахер, я лучше с нуля напишу.
no subject
Date: 2012-10-20 10:15 pm (UTC)no subject
Date: 2012-10-20 10:30 pm (UTC)no subject
Date: 2012-10-22 06:36 am (UTC)no subject
Date: 2012-10-21 07:40 am (UTC)no subject
Date: 2012-10-21 08:09 am (UTC)no subject
Date: 2012-10-21 08:16 am (UTC)no subject
Date: 2012-10-21 08:54 am (UTC)no subject
Date: 2012-10-21 09:06 am (UTC)no subject
Date: 2012-10-22 08:35 am (UTC)