Бизнес-логика: Структура данных 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-19 07:31 pm (UTC)no subject
Date: 2012-10-19 07:59 pm (UTC)Если несколько разных подсистем обращаются некоторым одинаковым образом к БД - можно подумать о том, чтобы выделить такие повторяющиеся (и достаточно низкоуровневые, относительно содержимого БД) функции в хранимые процедуры, чтобы избежать дублирования. Но не бизнес-логику.
Ограничения в БД могут быть, но могут и не быть, т.к. бизнес-логика, как правило, накладывает свои (сужающие, заложенные в структуре БД) ограничения.
no subject
Date: 2012-10-19 08:05 pm (UTC)Про важность структуры данных большое ДА! Если данные (и их модальности) не проебали, то их можно хоть через сто лет обработать новым кодом под новые обстоятельства. А если опаньки, то криптоархеологи и вуду-ритуалы не спасут.
no subject
Date: 2012-10-19 08:30 pm (UTC)Безнес-логика бизнеса? Или бизнес-логика раеализации бизнес-логики?
В первом случае структуры данных этой логике пох, она на другом уровне оперирует...
no subject
Date: 2012-10-19 08:36 pm (UTC)Или там, например, двойная запись в бухгалтерии - наличие двух идентичных по смыслу половин проводки - это относится к структуре данных гораздо больше, чем к коду, обрабатывающему данные.
no subject
Date: 2012-10-19 08:41 pm (UTC)Что не означает, как вы правильно заметили, необходимости хранить логику бизнеса в структурах данных. Умело запроектированная БД - благо и нимб на голову аналитика.
no subject
Date: 2012-10-19 09:00 pm (UTC)осуждаюскажу за entity–attribute–value model поверх реляционной БД и любая хня данных настраивается по месту, а бизнес-логика от данных реально абстрагирована и вообще она на 83% настраивается внедренцем по месту, в гламурной административной консольке.no subject
Date: 2012-10-19 09:04 pm (UTC)Есть, есть люди, которые считают, что бизнес-логика должна быть в BPMS, а в структуре данных (АКА информационный объект) не должно быть сведений о текущем статусе этого объекта...
no subject
Date: 2012-10-19 09:05 pm (UTC)А про структуры данных — надо сначала определить, что такое данные.
Вот например, лямбдо-исчислёниё-функция — это данные? ;-)
А то вот, замкнулись в своём SQL!
Есличо, я тут не говорю, что как будто, в этом есть что-то плохое ;-)
no subject
Date: 2012-10-19 09:10 pm (UTC)no subject
Date: 2012-10-19 09:12 pm (UTC)no subject
Date: 2012-10-19 09:12 pm (UTC)no subject
Date: 2012-10-19 09:45 pm (UTC)а вы тут бизнес-логика, структура даанных :)
no subject
Date: 2012-10-19 09:45 pm (UTC)no subject
Date: 2012-10-19 09:46 pm (UTC)- да унылое говно в каментах на самом деле. т.е. вот реально там например отличился не совсем мудак в споре с мускулистым совсем мудаком. похабнейшее зрелище.
какие-то отморози, называщие постгре "постгрой".
и как всегда, 100% участников этого блядского срача вообще никогда не работали с ораклями.
т.е. вот даже не с Database'ом не работали, не говоря уШ о мидлваре, соа там или бпм.
это например мода такая в говне и торфе рассуждать о незнакомых и чуждЫх вещах?
no subject
Date: 2012-10-19 10:08 pm (UTC)no subject
Date: 2012-10-19 10:08 pm (UTC)no subject
Date: 2012-10-19 10:19 pm (UTC)no subject
Date: 2012-10-19 10:25 pm (UTC)no subject
Date: 2012-10-19 10:40 pm (UTC)no subject
Date: 2012-10-19 10:49 pm (UTC)А сортировочка и так весёлая, вроде. :)
no subject
Date: 2012-10-19 10:57 pm (UTC)А уж что за причина - это явно никому не интересно
no subject
Date: 2012-10-19 11:18 pm (UTC)больше ада!
no subject
Date: 2012-10-19 11:19 pm (UTC)no subject
Date: 2012-10-19 11:22 pm (UTC)