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

[metaclass]

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

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

Comments

[vromanov.livejournal.com]

Ты открыл NoSQL!

[shlyahtich.livejournal.com]

Походит на ересь!

[astoon.livejournal.com]

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

[guamoka.livejournal.com]

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


Ребе, боб с горохом:-) Никто ничего не реализует за кого-то. В общем-то все эти вопросы транзакционности, секьюрити, скажем, в JEE, достаточно обширные, но секьюрити на апп-сервере и на базе- это две независимые вещи, так же не имеет значение, кто открывает и координирует транзакцию- апп-сервер, jdbc-драйвер (клиетское десктоп приложение) или какой-либо другой транзакш менеджер в рамках своей модели.
А на мое имхо, это RDB(MS)ы- вудуистские вещи в себе. Чтобы вытащить данные на свет божий из мрака теории множеств и связей на них надо плясать с бубном, потому что RDB(MS) и SQL, такое впечатление, только и годятся на то, чтобы достать данные из таблицы, достать зависимые данные, смержить-сжойнить, отфильтровать и положить в другую таблицу, либо отобразить в достаточно простой форме бухгалтерского отчета. Короче, вещь в себе, с крайне узким интерфесом с реальным миром.

[jamhed.livejournal.com]

SQL для того и придумали чтобы собирать произвольные отчёты по стереотипным данным стереотипным образом - не зря ж там буква Q. И для этих целей подходит как нельзя лучше.

А вот для целей организации хранилищ объектов и программирования(!) бизнес-логики как нельзя хуже.

И зачем, спрашивается, гвозди забивать неподходящими предметами?

[dmzlj.livejournal.com]

и данные туда-сюда летают через сокеты, и оптимизации запросов никакой (какая еще оптимизация в жирном сервере приложений?) А row-level пермиссии небось вообще красота --- если я себе представляю как и кем написан средний сервер приложений --- то натурально берут рекорд сет, высасывают его весь и проверяют пермиссии на каждую строку. Красота!

[ennor.livejournal.com]

Беда, коль пироги возьмется печь сапожник (с)

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

А когда возникает потребность написать Насдак, то в любом случае на таком проекте будут нормальные архитекторы, ДБДевы, клиентщики и т.д. И базы будут выполнять те вещи, которые быстрее и органичнее делаются на их стороне, а middle tier заниматься своим делом.

[blackyblack.livejournal.com]

Высказанная идея хороша. Можно было бы замутить стартап - хорошая субд без лишних наворотов.
Вопрос в том, чем лучше хранить бизнес логику на аппликейшн сервере, чем на субд сервере. И так и этак получается сложности в отладке, апгрейде, деплойменте и растёт общая сложность проекта. Бизнес логику нужно хранить в коде и нигде больше.

Работаете? Ну-ну

[plumqqz.livejournal.com]

Спортивного интереса для советую посмотреть на BerkeleyDB посерьезней. Так вот, при более серьезном рассмотрении Вы выясните, что bdb представляет из себя недоделанный фундамент нормальной субд (который, безусловно, во многих случаях может быть полезен), и надо постоянно отслеживать всякие интимные базоданновые радости, которые обычные СУБД скрывают (например, при старте приложения надо обязательно начать процедуру восстановления базы, если, конечно, кто-то ее уже не восстанавливает). Надо быть постоянно готовым к отказу БД (а так как это C, то нарваться можно совершенно неожиданно) и т.п. Примерно представляя себе среднего жабиста-похаписта я ОЧЕНЬ сомневаюсь, что они смогут допилить свое приложение до требуемого тем же bdb уровня. Не потому что такие тупые, а потому что не в курсе.

Не надо забывать, что и о оптимизации запросов жабист - средний похапист имеет обычно самые дикие представления. Так как писать все писать ручками с bdb надоедает удивительно быстро, я легко могу себе представить тот ужас, который будет создан. Так что увы - оптимизатор БД обычно много умнее среднего и тем более слабого разработчика, и сильнее расслабленного хорошего.

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