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

Entry tags:

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

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

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

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

Flat | Top-Level Comments Only

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

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

Руками-не руками, какая разница? Таргет-платформа не понимает ваши запросы от предыдущей платформы. Потому что никакой сейчас не 92й год :)

какой МОЙ запрос. запрос генерит орм-или-его-аналог. я тупо пишу что то вида: `Point.where(:created_at => Time.now.beginning_of_day .. Time.now).where(:customer_id => [1, 2, 10]).order(:name).all` и мне реально похер какая там база и какой говносрез недострандарта сикль она умеет. кампутир железный, пусть он думает.

и да - в 99% случаев оно сгенерит оптимальный запрос. да, оно умеет и джоины-хуёины и всё что надо. при этом никто не запрещает при попадании в тот 1% когда запрос не совсем оптимален и когда важна скорость написать селект какой руками. за последние 6 лет я сделал такое один раз и то по причине того что не знал что тот орм умеет вложенные прелоады.

Ага, потом для того, чтобы обновить поле у 100500 записей, все они ОРМом подтягиваются на клиент, потом в цикле у них изменяется значение, и , наконец, все это дело летит обратно на сервер. Потом начинает это все начинает тормозить, жрать память и тд, потом изобретается что-то вроде обновлений партиями по 500 штук и прочая ерунда.

А вот тут мы подошли к самому интересному моменту нашего обсуждения. 83% продуктов на рынке на фазе своей разработки имеют только одну цель: быть завершенными. Что там будет дальше в жизненном цикле - никого не волнует. А если мы о стартапе, целью которого будет продажа дальше по цепочке, то о таком вообще запрещено думать, чтобы не мутить воду.

Я придерживаюсь мнения, что сначала надо сделать самым простым наивным способом, чтобы работало и можно было тестировать. У меня какие-то похожие с Айседом значения, что 98-99% задач делается ОРМом, а остальное можно и руками похардкодить. Просто он говорит, мол мощные хранимки и специфичные особенности конкретной СУБД - зло, потому что если вендер субд поехал, то все дружно попали ад. По мне так, это не аргумент ни разу. Какбы если с ума сойдут (или просто забьют на развитие и поддержку) разрабы ОРМ, то проблем будет гораздо-гораздо больше. И что теперь паниковать и воротить слой абстракции над ОРМами? Не думаю. Это ни к чему хорошему не приведет. Когда растут нагрузки придется спускаться к СУБД-специфичными фичам, когда надо делать бэкапы базы тоже чаще всего надо пользоваться СУБД-специфичными тулзами, когда надо секьерность-пользователи-права тоже все СУБД-специфичное, апдейты для базы я тоже руками пишу, хотя вроде есть какие-то там миграторы, но я опять же им не верю. Ко всему прочему, когда это дело год или два на конкретной СУБД работает, то оно оттестировао, пробелемы известны и саппорт умеет их чинить, без пробрасывания геморроя в наш отдел. А если там зверинец поддерживаемых СУБД развести, то нам, наверное, придется человека выделять. который будет рулить все енти вопросы. СУБД же все по разному работают, разные планы запросов строят, по-раному нуллы трактуют, еще с датавременем и гуидами какие-то проблемы у меня были. То есть вопрос масштаба, я считаю. Когда там code-first и надо прототип слепить, пофиг что там за постоянное хранилище, а когда пошла реальная работа с загрузкой ресурсов, то все эти абстракции прилетают бумерангом по башке.

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

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

Я такого поведение не наблюдал, а вот "тысячи объектов материализуются лишь для того, чтобы по ним нагерерился update" правил буквально на днях. Я ОРМам не верю, потому любое свое предположение относительно их работы приходится тестирвоать, потому если время поджимает, я лучше руками нарисую SQL-зпапрос и заверну его в метод репозитория в модели, а еще лучше сделаю из ентого запроса такую-то хранимку, потому что у нее выше шанс реиспользования.

Обновление на сервере:

db.Employee
.Where(e => e.Title == "Spectre")
.Set(e => e.Title, "Commander")
.Update();

Люди написали один единственный ОРМ-фреймворк, ага.

В тех, в которых такое невозможно - да, ручной запрос.
Если уж говорить за ОРМ - то правильные являются тонкой надстройкой над базой и не занимаются самодеятельностью по созданию и загрузке данных.

это хуёвые ормы, нормальные сгенерят правильный апдэйт.

Как выглядит такой апдейт? можешь привести пример?

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

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

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

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

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

(no subject)

metaclass.livejournal.com - 2012-10-21 08:08 (UTC) - Expand

(no subject)

theiced.livejournal.com - 2012-10-21 08:54 (UTC) - Expand

(no subject)

metaclass.livejournal.com - 2012-10-21 09:05 (UTC) - Expand

(no subject)

metaclass.livejournal.com - 2012-10-21 09:05 (UTC) - Expand

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

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

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