![[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
а все функции, которые может делать СУБД - реализуют средствами сервера приложений. Т.е. и транзакции (не дай бог распределенные с разными СУБД) и права доступа(которые в разных серверах вообще по разному сделаны) и сборка объектов предметной области из записей в БД - все это делается на каком-нибудь жабодотнете
Ребе, боб с горохом:-) Никто ничего не реализует за кого-то. В общем-то все эти вопросы транзакционности, секьюрити, скажем, в JEE, достаточно обширные, но секьюрити на апп-сервере и на базе- это две независимые вещи, так же не имеет значение, кто открывает и координирует транзакцию- апп-сервер, jdbc-драйвер (клиетское десктоп приложение) или какой-либо другой транзакш менеджер в рамках своей модели.
А на мое имхо, это RDB(MS)ы- вудуистские вещи в себе. Чтобы вытащить данные на свет божий из мрака теории множеств и связей на них надо плясать с бубном, потому что RDB(MS) и SQL, такое впечатление, только и годятся на то, чтобы достать данные из таблицы, достать зависимые данные, смержить-сжойнить, отфильтровать и положить в другую таблицу, либо отобразить в достаточно простой форме бухгалтерского отчета. Короче, вещь в себе, с крайне узким интерфесом с реальным миром.
no subject
RDBMS вудуистские не из-за интерфейса и не из-за теории множеств. Как раз реляционная модель и ее представление в виде таблиц - это единственный вариант адекватной работы с большими объемами данных, теорию которого можно уместить в мозг и не сойти с ума.
Там проблемы в другом - наворачивание дополнительных функций в несовместимом друг с другом виде, проблемы с версионностью схемы, несовместимость без извращений с другими моделями данных и прочее.
no subject
Ну и в чем идиотизм? АппСервер- это не надстройка над БД. БД, по большому счету, вообще может не быть. Или может быть какая-нибудь облегченная-втроенная типа HSQLDB или Derby. А может быть еще куча сервисов типа JMX, Mail и, конечно, Web. Вот зачем, скажем, вам второй глаз. Он ведь, например, у жены вашей есть? %-)
это единственный вариант адекватной работы с большими объемами данных
Ну да, только данные эти странные: служащий-отдел-зарплата. Если бы теория множеств была всеохватывающей, то, вероятно, не существовало, скажем, теории графов, и связанных ATD. Хотя да, граф- это тоже множество. Но вот чтобы смоделировать его на БД и обработать естественным путем, используя всю мощь DB по работе с большими объектами данны, - начиная от простейших бинарных деревьев и заканчивая сетями- тут уже начинаются пляски, потому что реализация ТМ в виде RDB - это даже не ассемблер, над которым спокойно и однозначно надстраивается язык высокого уровня и разные парадигмы программирования типа процедурного/объектного.
no subject
Отражение графов в RDB не настолько хорошо теоретически проработано, чтобы это использовалось повмеместно и единообразно. Я видел работы на эту тему, но они все, мягко выражаясь, не дотягивают до классических работ по реляционным моделям. Поэтому все реализации сделаны печальным полуэмпирическим образом, а практики вон до сих пор не могут придти к согласию на тему "RDB vs RDB+ORM vs NoSQL".
Для того, чтобы адекватно описать хранение графа данных и требования к нему (время доступа, затраты памяти и прочее) сейчас и нотации то нормальной нет, не говоря уже об ее автоматической конверсии в схему данных. А если ее сделать - все равно никто пользоваться не будет, ибо слишком заумно.
no subject
Ребе, я не знаю, где я вам делаю смешно:-) Мы не говорим про маргинальные языки для алиты:-) Мы говорим про традиционные языки для простых быдлокодеров, которые уже вилзаны вдоль и поперек.
С Java я могу быть уверенным, что компилятор и виртуальная машина не будут додумывать за меня, что я хотел сказать, а будут оптимизировать только то, что могут, и если я правильно выбрал ATD и алгоритм (по хорошо известным и детерминированным высокоуровневым критериям), то в общем случае, я могу быть уверенным, что моя программа в заданном интервале значений отработает за постоянное (+\-) время.
Но. Мне не нравится, что результаты работы моего запроса могут поменяться от порядка перечисления таблиц в where, наличия или отсутствия собранной статистики и количества данных, на которых эта статистика собиралась, количества данных вообще, даже если эти данные не отвечают текущему запросу. И проч., и проч. Я конечно понимаю, что в базе выбор алгоритма обработки и структуры данных, о котором я говорил в начале, на самом деле, как бы получается реализуется в общем случае и в ад-хок, реал-тайм режиме. Но мне от этого не легче, потому что теряется предсказуемость. Конечно, гуру БД, только и занимавшийся тем, что "оптимизировал запросы", сможет на глаз определить многие потенциальные фак-апы и боттл-неки. Но это, повторюсь, уже сродни тому, чтобы каждый программист занимался оптимизацией даже банального кода за компилятор и среду выполнения.
сейчас и нотации то нормальной нет
Есть вполне адекватные программные типы данных (4-е, если не изменяет память: adjacency и incidence, lists и matrix) для хранения деревьев и обработки с вполне внятными критериями выбора той или иной в зависимости от нужд. Другое дело, когда естественные структуры пытаются натянуть на неприспособленную для этого модель.
no subject
И, кстати, если уж про оптимизацию - работа с БД на данный момент эквивалентна разработке программ, заточенных под тонкости работы отдельных процессоров, их кэшей и тому подобной ереси. Чисто в силу того, что вычислительная и i/o нагрузка намного больше, чем у средней проги.
no subject
no subject
(ну, не совсем, но...)
no subject