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

[metaclass]

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

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

Comments

[vromanov.livejournal.com]

Ты открыл NoSQL!

[metaclass.livejournal.com]

Это не NoSQL, т.к. мне религия запрещает использовать базы данных без запросов и статической схемы :)
Другое дело, что и то и другое придется реализовать самому, причем, если делать по человечески, это потянет за собой такое вуду, которое будет сложнее чем саппорт баз на оракле:)

[vromanov.livejournal.com]

Такое вуду уже есть. К последнему BerkeleyDB прикрутили SQL от SQLite3.

[metaclass.livejournal.com]

SQLite малость печален, странной типизацией и неполноценным SQL.

[nivanych.livejournal.com]

Ну так sqlite и предназначен-то для чего?
Типизация странная, но в остальном у меня к нему претензий нет.

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

[http://users.livejournal.com/_slw/]

i18n у него (sqlite) в жопе чуть более чем полностью.

[nivanych.livejournal.com]

Да, совсем забыл...
Ну, ничо. Не всегда это так жопно.

[alll]

Так. MySQL ещё толком не помер, а уже заработал переселение душ.

[metaclass.livejournal.com]

Кровосмешение и содомский грех это а не переселение душ :)

[alll]

сон смерти не помеха

[vromanov.livejournal.com]

Это совсем другое. Теперь у оракла стало 4 нормальных базы

[b00ter.livejournal.com]

Это именно NoSQL. Статическая схема зло, особенно если ее рассматривать в динамике (версионность, ага), а map-reduce ничуть не хуже языка запросов, особенно в вэбне, где каждое второе чмо норовит injection подкинуть.

Да-да, плюйте в меня, православные скуэльшики!

[teewoon.livejournal.com]

*сиквельщики

[metaclass.livejournal.com]

Насчет статики это вообще религиозный вопрос.

Я не могу заставить себя писать тестов больше чем кода, а тут нет альтернативы - или статическая типизация и гарантия корректности программы или 100% покрытие тестами.

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