+1, согласен с вами. Разговоров много, интересных и познавательных, а вот кода нет, ни в статье, ни в комментах. Было бы здорово подискутировать, предложить разные варианты.
И вообще я считаю, что должно быть не «ORM vs stored procedures», а «ORM+stored procedures», т.е. есть своя инфраструктура на стороне базы (набор базовых процедур для работы с данными, набор процедур бизнесс логики, функции(вьюхи) для представления данных и др.) и есть ORM, которая предоставляет объектную обертку (и не только).
Т.о. используется мощь ОРМ, и БД не представляет собой набор плоских тупых таблиц, а используются все ее специализированные функции.
Мешает то, что языки в БД не имеют средств чтобы строить хорошие абстракции.
У меня вот, например, на реальном проекте в ORM-ке во многих таблицах есть createdby/whem/modifiedby/when, это строчек в 10-20 кода сделано и совершенно прозрачно для прикладного кода — т.е. нельзя забыть заполнить, нельзя заполнить неправильно. В БД можно такое сделать триггерами, но пришлось бы вешать по триггеру на каждую таблицу.
А вот это имхо не очень сильный аргумент. В более менее крупных приложениях БД редко когда размазывают инсерты (апдейты, делиты и т.д.) по коду. Так же определяют слой доступа к данным, т.е процедуры, у которых могут быть такие же поля как вы описали, тоже ничего не забудешь и не ошибешься (проверки, значения по умолчанию). А вот триггеров (по крайней мере в тех проектах в которых учавствовал) стараются избегать, а если и делают, то вызываются в них те же самые хранимые процедуры.
Но соглашусь, что в ORM это более развито, больше инструментов, готовых решений, а в базе многое приходится делать и продумывать самостоятельно.
Потом у меня есть слой для прав доступа. Прикладной код может делать любые запросы к БД, но проходя через этот слой на них навешиваются where с фильтрацией, и прикладной код не может достать то, чего не положено текущему юзеру видеть. Это тоже сделано более-менее универсально, и навешивается централизованно. В БД такое тоже можно сделать вьюшками, но опять же надо будет по вьюшке на таблицу.
То же сомнительный аргумент. Помимо вьюшек (кстати весьма мощный и гибкий инструмент) есть хранимые функции, которые могут возвращать наборы данных (а их в свою очередь можно использовать в других функциях). Если это Оракл, то есть специализированная штука DBMS_RLS, заточенная под разделение прав лучше (т.к. это родное решение для базы) любой ОРМ.
Также можно делать денормализацию, кэширование, аудит, раскладывание данных по разным базам, всякие push-нотификации. И все это — без вмешательства в прикладной код.
Все вышеперечисленное входит в большинство современных промышленных СУБД (в Оракл уж точно).
Что значит 'изменения вручную'? Если работаете с исходниками, то никакой общей рабочей эталонной базы может и не быть. У каждого разработчика может быть своя база, которую он соберет из исходников, и что он там в ручную сделает — никто не узнает, главное — что будет в репозитории.
По моему, перечисленным СКВ все равно что хранить: код java-программы, PLSQL или текст художественного романа. Это уже опять же от разработчика зависит как он туда поместит свой код и как достанет. Есть много решений, которые сканируют базу и обновляют(создают) фалйы в репозитории. Если со всем по крутому, то хорошо создавать объекты БД непосредственно в файлах, организовать собственную структуру каталогов (в этой папке таблицы, в этой процедуры и т.д.) и отдать под контроль СКВ. Сборщиков и миграторов тоже хватает (тот же мега популярный ликвибэйс например и другие). А вот с инструментом, который бы смог организовать структуру хранения объектов в файлах, легко добавлять их и легко извлекать, имхо проблема. У меня есть пару идей и наработок на эту тему, если интересно поделюсь.
Ничто не мешает сделать такое разделение в бд, на уровне хранимок. Есть слой процеур для низкоуровневой работы с данными, есть слой бизнесс логики и т.д.
А почему РСУБД должна поддерживать версионность кода хранимых процедур? Имхо это то же самое, что требовать версионности от компилятора C. Это задача разработчика.
Думаю такой инструмент может пригодится там, где регулярку (пусть и простую) нужно написать пользователю какого-либо приложения (далекому от regex или успевшему хорошо забыть), например для конфигурационных файлов, настроек и т.д.
Спасибо, хорошая статья. За пункт №8 голосую дополнительно «за».
ПС
ИМХО немного картинка смутила, т.к. часто используется в такой тематике. Сразу возникла мысль: «а не старая ли это статья?». Но прочев несколько первых предложений все понял.
На гитхаб (или что то похожее) не хотите выложить? а то имхо как то не солидно исходники на файлообменниках хранить. Да и вам сасмому с СКВ удобнее будет работать, даже если один трудитесь.
Один мой преподаватель советовал повторять всю подготовку к экзамену на следующийь день после самого экзамена (хотя бы частично), говорил, что т.о. можно запомнить информацию на всю жизнь.
Но я его к сожалению не послушал…
Т.о. используется мощь ОРМ, и БД не представляет собой набор плоских тупых таблиц, а используются все ее специализированные функции.
А вот это имхо не очень сильный аргумент. В более менее крупных приложениях БД редко когда размазывают инсерты (апдейты, делиты и т.д.) по коду. Так же определяют слой доступа к данным, т.е процедуры, у которых могут быть такие же поля как вы описали, тоже ничего не забудешь и не ошибешься (проверки, значения по умолчанию). А вот триггеров (по крайней мере в тех проектах в которых учавствовал) стараются избегать, а если и делают, то вызываются в них те же самые хранимые процедуры.
Но соглашусь, что в ORM это более развито, больше инструментов, готовых решений, а в базе многое приходится делать и продумывать самостоятельно.
То же сомнительный аргумент. Помимо вьюшек (кстати весьма мощный и гибкий инструмент) есть хранимые функции, которые могут возвращать наборы данных (а их в свою очередь можно использовать в других функциях). Если это Оракл, то есть специализированная штука DBMS_RLS, заточенная под разделение прав лучше (т.к. это родное решение для базы) любой ОРМ.
Все вышеперечисленное входит в большинство современных промышленных СУБД (в Оракл уж точно).
Т.е. альтернатива есть всегда.
Помимо электроники есть еще отличные чисто инструментальные вещи (в совершенно разных стилях), там где слова тоже не мешают.
ПС
ИМХО немного картинка смутила, т.к. часто используется в такой тематике. Сразу возникла мысль: «а не старая ли это статья?». Но прочев несколько первых предложений все понял.
Но я его к сожалению не послушал…