SQL DBMS vs самодельные базы из Berkeley DB, жаб, червей и змей

[metaclass]

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

Так вот, нафиг тут тогда SQL/реляционные СУБД? Если взять что-нибудь вроде Berkeley DB, сделать для нее все те же самые функции, за исключением того, что конечный пользователь будет волен по желанию выкинуть нахрен, например, стандартное управление версионностью и запилить свое, или там не хочет он SQL в качестве языка запросов, а хочет какой-нибудь LINQ или тому подобные монады.
Т.е. практически, мы возвращаемся к давно выкинутой в пользу RDBMS идее самодельных наколенных баз данных, но на сей раз, в силу всеобщей засранности индустрии придурочными технологиями никто слова поперек не скажет, что называется, абы работало. Ну и опять же - сейчас выбор готового шрота, из которого можно клепать такую чушь сильно больше, чем это было 10-15 лет назад.

Comments

[metaclass.livejournal.com]

Тем не менее, бизнес-логику на СУБД делают в массовых масштабах и гордятся этим.

[jamhed.livejournal.com]

Делают. Стоит ли этим гордится - вот вопрос :)

[sbj-ss.livejournal.com]

> Причем из каких-то религиозных (а на самом деле весьма практических - избежать гемора с поддержкой и обновлениями) соображений количество логики в БД стараются минимизировать
Ой, вот ну нафиг. Всё, что может быть по смыслу написано на хранимых процедурах с нормальной производительностью, на них и должно быть написано. Ко всем данным, отчётам и тдтп, где схема может измениться - доступ с помощью хранимых процедур, чтобы не ломать потом приложение каждый раз. SQL где-то неэффективен - некритично, M$SQL поддерживает расширенные хранимые в двоичном коде и сборки .NET.
Т.е. всю бизнес-логику имхо проще держать в базе, даже если это превращается в ужасы с каскадными триггерами.

[jamhed.livejournal.com]

Когда в руках молоток, все вокруг похоже на гвоздь!