![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
SQL DBMS vs самодельные базы из Berkeley DB, жаб, червей и змей
Сижу допиливаю кодогенератор и в силу забубенности тематики мозг начинает параллельно думать на смежные темы.
Сейчас SQL базы данных часто используются как тупые хранилища данных. Доступ к ним производится посредством какого-тонаписанного тупыми индусами сервера приложений. Причем из каких-то религиозных (а на самом деле весьма практических - избежать гемора с поддержкой и обновлениями) соображений количество логики в БД стараются минимизировать, а все функции, которые может делать СУБД - реализуют средствами сервера приложений. Т.е. и транзакции (не дай бог распределенные с разными СУБД) и права доступа(которые в разных серверах вообще по разному сделаны) и сборка объектов предметной области из записей в БД - все это делается на каком-нибудь жабодотнете. Причем делается, я бы сказал, гораздо печальнее и многословнее чем это сделано в СУБД, но зато проще в разработке и поддержке.
Так вот, нафиг тут тогда SQL/реляционные СУБД? Если взять что-нибудь вроде Berkeley DB, сделать для нее все те же самые функции, за исключением того, что конечный пользователь будет волен по желанию выкинуть нахрен, например, стандартное управление версионностью и запилить свое, или там не хочет он SQL в качестве языка запросов, а хочет какой-нибудь LINQ или тому подобные монады.
Т.е. практически, мы возвращаемся к давно выкинутой в пользу RDBMS идее самодельных наколенных баз данных, но на сей раз, в силу всеобщей засранности индустрии придурочными технологиями никто слова поперек не скажет, что называется, абы работало. Ну и опять же - сейчас выбор готового шрота, из которого можно клепать такую чушь сильно больше, чем это было 10-15 лет назад.
Сейчас SQL базы данных часто используются как тупые хранилища данных. Доступ к ним производится посредством какого-то
Так вот, нафиг тут тогда SQL/реляционные СУБД? Если взять что-нибудь вроде Berkeley DB, сделать для нее все те же самые функции, за исключением того, что конечный пользователь будет волен по желанию выкинуть нахрен, например, стандартное управление версионностью и запилить свое, или там не хочет он SQL в качестве языка запросов, а хочет какой-нибудь LINQ или тому подобные монады.
Т.е. практически, мы возвращаемся к давно выкинутой в пользу RDBMS идее самодельных наколенных баз данных, но на сей раз, в силу всеобщей засранности индустрии придурочными технологиями никто слова поперек не скажет, что называется, абы работало. Ну и опять же - сейчас выбор готового шрота, из которого можно клепать такую чушь сильно больше, чем это было 10-15 лет назад.
Работаете? Ну-ну
Не надо забывать, что и о оптимизации запросов жабист - средний похапист имеет обычно самые дикие представления. Так как писать все писать ручками с bdb надоедает удивительно быстро, я легко могу себе представить тот ужас, который будет создан. Так что увы - оптимизатор БД обычно много умнее среднего и тем более слабого разработчика, и сильнее расслабленного хорошего.
Мне, признаться, эта затея кажется в высшей степени бесперспективной, хотя веселья будет предостаточно. Как говорил К.Прутков "Некоторые вещи нам непонятны не потому, что наши понятия об этих вещах слабы, но потому, что вещи сии не входят в круг наших понятий".
Re: Работаете? Ну-ну
Ну да. Жабистам, которые не в курсе, например, так же не придет в голову выполнять оптимизацию кода вручную за Java-компилятор и JVM:-) Просто достаточно выполнять довольно четкие правила с предсказуемым результатом, и иметь общее представление о том, как работает компилятор/JVM. Хотя, казалось бы, вот вам в руки JNI, и вперед...
Re: Работаете? Ну-ну
Нежабистам вообще неизмеримо лучше: их такие задачи не волнуют.
Впрочем, по основному вопросу, как я вижу, возражений нет. Консенсус достигнут, это радует.
Re: Работаете? Ну-ну
Re: Работаете? Ну-ну