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% покрытие тестами.

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

[shlyahtich.livejournal.com]

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

[astoon.livejournal.com]

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

[guamoka.livejournal.com]

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


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

[metaclass.livejournal.com]

Ну вот два независимых варианта cекьюрити - это уже идиотизм. Как и повторная реализация SQL в виде LINQ и отдельные менеджеры транзакций.

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

[guamoka.livejournal.com]

Ну вот два независимых варианта cекьюрити - это уже идиотизм.

Ну и в чем идиотизм? АппСервер- это не надстройка над БД. БД, по большому счету, вообще может не быть. Или может быть какая-нибудь облегченная-втроенная типа HSQLDB или Derby. А может быть еще куча сервисов типа JMX, Mail и, конечно, Web. Вот зачем, скажем, вам второй глаз. Он ведь, например, у жены вашей есть? %-)

это единственный вариант адекватной работы с большими объемами данных

Ну да, только данные эти странные: служащий-отдел-зарплата. Если бы теория множеств была всеохватывающей, то, вероятно, не существовало, скажем, теории графов, и связанных ATD. Хотя да, граф- это тоже множество. Но вот чтобы смоделировать его на БД и обработать естественным путем, используя всю мощь DB по работе с большими объектами данны, - начиная от простейших бинарных деревьев и заканчивая сетями- тут уже начинаются пляски, потому что реализация ТМ в виде RDB - это даже не ассемблер, над которым спокойно и однозначно надстраивается язык высокого уровня и разные парадигмы программирования типа процедурного/объектного.

[metaclass.livejournal.com]

Язык высокого уровня однозначно надстраивается над ассемблером? Вы делаете мне смешно, посмотрите хотя бы реализацию хаскеля в GHC. Там же ад кромешный. Как раз те самые графы.

Отражение графов в RDB не настолько хорошо теоретически проработано, чтобы это использовалось повмеместно и единообразно. Я видел работы на эту тему, но они все, мягко выражаясь, не дотягивают до классических работ по реляционным моделям. Поэтому все реализации сделаны печальным полуэмпирическим образом, а практики вон до сих пор не могут придти к согласию на тему "RDB vs RDB+ORM vs NoSQL".

Для того, чтобы адекватно описать хранение графа данных и требования к нему (время доступа, затраты памяти и прочее) сейчас и нотации то нормальной нет, не говоря уже об ее автоматической конверсии в схему данных. А если ее сделать - все равно никто пользоваться не будет, ибо слишком заумно.

[guamoka.livejournal.com]

Вы делаете мне смешно, посмотрите хотя бы реализацию хаскеля в GHC.

Ребе, я не знаю, где я вам делаю смешно:-) Мы не говорим про маргинальные языки для алиты:-) Мы говорим про традиционные языки для простых быдлокодеров, которые уже вилзаны вдоль и поперек.

С Java я могу быть уверенным, что компилятор и виртуальная машина не будут додумывать за меня, что я хотел сказать, а будут оптимизировать только то, что могут, и если я правильно выбрал ATD и алгоритм (по хорошо известным и детерминированным высокоуровневым критериям), то в общем случае, я могу быть уверенным, что моя программа в заданном интервале значений отработает за постоянное (+\-) время.

Но. Мне не нравится, что результаты работы моего запроса могут поменяться от порядка перечисления таблиц в where, наличия или отсутствия собранной статистики и количества данных, на которых эта статистика собиралась, количества данных вообще, даже если эти данные не отвечают текущему запросу. И проч., и проч. Я конечно понимаю, что в базе выбор алгоритма обработки и структуры данных, о котором я говорил в начале, на самом деле, как бы получается реализуется в общем случае и в ад-хок, реал-тайм режиме. Но мне от этого не легче, потому что теряется предсказуемость. Конечно, гуру БД, только и занимавшийся тем, что "оптимизировал запросы", сможет на глаз определить многие потенциальные фак-апы и боттл-неки. Но это, повторюсь, уже сродни тому, чтобы каждый программист занимался оптимизацией даже банального кода за компилятор и среду выполнения.

сейчас и нотации то нормальной нет
Есть вполне адекватные программные типы данных (4-е, если не изменяет память: adjacency и incidence, lists и matrix) для хранения деревьев и обработки с вполне внятными критериями выбора той или иной в зависимости от нужд. Другое дело, когда естественные структуры пытаются натянуть на неприспособленную для этого модель.

[metaclass.livejournal.com]

Шо такое ATD?

И, кстати, если уж про оптимизацию - работа с БД на данный момент эквивалентна разработке программ, заточенных под тонкости работы отдельных процессоров, их кэшей и тому подобной ереси. Чисто в силу того, что вычислительная и i/o нагрузка намного больше, чем у средней проги.

[guamoka.livejournal.com]

ADT, угу.

[kisa-i-osya.livejournal.com]

Похоже, описывется Cache' и M-системы ;-)

(ну, не совсем, но...)

[pete-by.livejournal.com]

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

[jamhed.livejournal.com]

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

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

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

[metaclass.livejournal.com]

Тем не менее, бизнес-логику на СУБД делают в массовых масштабах и гордятся этим.

[jamhed.livejournal.com]

Делают. Стоит ли этим гордится - вот вопрос :)

[sbj-ss.livejournal.com]

> Причем из каких-то религиозных (а на самом деле весьма практических - избежать гемора с поддержкой и обновлениями) соображений количество логики в БД стараются минимизировать
Ой, вот ну нафиг. Всё, что может быть по смыслу написано на хранимых процедурах с нормальной производительностью, на них и должно быть написано. Ко всем данным, отчётам и тдтп, где схема может измениться - доступ с помощью хранимых процедур, чтобы не ломать потом приложение каждый раз. SQL где-то неэффективен - некритично, M$SQL поддерживает расширенные хранимые в двоичном коде и сборки .NET.
Т.е. всю бизнес-логику имхо проще держать в базе, даже если это превращается в ужасы с каскадными триггерами.

[jamhed.livejournal.com]

Когда в руках молоток, все вокруг похоже на гвоздь!

[dmzlj.livejournal.com]

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

[metaclass.livejournal.com]

Это еще хорошо, если они тот рекордсет итератором высасывают, а не целиком в память :)

[ennor.livejournal.com]

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

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

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

[blackyblack.livejournal.com]

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

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

[plumqqz.livejournal.com]

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

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

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

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

[guamoka.livejournal.com]

Не потому что такие тупые, а потому что не в курсе.

Ну да. Жабистам, которые не в курсе, например, так же не придет в голову выполнять оптимизацию кода вручную за Java-компилятор и JVM:-) Просто достаточно выполнять довольно четкие правила с предсказуемым результатом, и иметь общее представление о том, как работает компилятор/JVM. Хотя, казалось бы, вот вам в руки JNI, и вперед...

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

[plumqqz.livejournal.com]

Ну да. Жабистам, которые не в курсе, например, так же не придет в голову выполнять оптимизацию кода вручную за Java-компилятор и JVM:-)

Нежабистам вообще неизмеримо лучше: их такие задачи не волнуют.
Впрочем, по основному вопросу, как я вижу, возражений нет. Консенсус достигнут, это радует.

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

[guamoka.livejournal.com]

Мир в себе всегда радует!

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

[plumqqz.livejournal.com]

Да-да, "ЛСД - раскрасьте мир сами!"