![[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 лет назад.
no subject
no subject
no subject
Типизация странная, но в остальном у меня к нему претензий нет.
А то, что прикрутили SQL, это очень хорошо.
Полноценный SQL тем, кто использует для своей задачи BerkeleyDB, не нужен, а вот некоторые элементы SQL очень даже нужны.
Посмотрю, может быть, мне пригодится.
no subject
no subject
Ну, ничо. Не всегда это так жопно.
no subject
no subject
no subject
no subject