![[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
no subject
no subject
Типизация странная, но в остальном у меня к нему претензий нет.
А то, что прикрутили SQL, это очень хорошо.
Полноценный SQL тем, кто использует для своей задачи BerkeleyDB, не нужен, а вот некоторые элементы SQL очень даже нужны.
Посмотрю, может быть, мне пригодится.
no subject
no subject
Ну, ничо. Не всегда это так жопно.
no subject
no subject
no subject
no subject
no subject
Да-да, плюйте в меня, православные скуэльшики!
no subject
no subject
Я не могу заставить себя писать тестов больше чем кода, а тут нет альтернативы - или статическая типизация и гарантия корректности программы или 100% покрытие тестами.
Версионность и статическая типизация совместимы, но тянут за собой редчайшее нечеловеческое вуду. Т.е. теоретически оно настолько сложно, что намного проще отслеживать это дело вручную и делать скрипты обновления схемы. Хотя это только потому, что обновления схемы делаются редко, а делаются редко они потому что иначе работа превратится в ад.
no subject
no subject
каждому сверчку свой шесток.
каждому хранилищу свои овощи.
каждому холодильнику... а, ладно, понятно в общем.
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
no subject
А вот для целей организации хранилищ объектов и программирования(!) бизнес-логики как нельзя хуже.
И зачем, спрашивается, гвозди забивать неподходящими предметами?
no subject
no subject
no subject
Ой, вот ну нафиг. Всё, что может быть по смыслу написано на хранимых процедурах с нормальной производительностью, на них и должно быть написано. Ко всем данным, отчётам и тдтп, где схема может измениться - доступ с помощью хранимых процедур, чтобы не ломать потом приложение каждый раз. SQL где-то неэффективен - некритично, M$SQL поддерживает расширенные хранимые в двоичном коде и сборки .NET.
Т.е. всю бизнес-логику имхо проще держать в базе, даже если это превращается в ужасы с каскадными триггерами.
no subject
no subject
no subject
no subject
Подавляющее большинство людей не в состоянии хорошо знать проектирование и разработку БД и клиентских приложений одновременно. Ну, сложно это, чисто из-за объема инфы, которую надо не просто знать - надо мыслить соответствующими категориями, не напрягаясь. Соответственно, один из компонентов всегда будет главным, а второй, соответственно, прослойкой. Но если получающийся продукт устраивает заказчиков и вписывается в ТЗ - да без проблем, пусть все хоть в XML-файлах хранят, если совсем с реляционным мышлением тяжко (у меня есть такая знакомая, которая вообще не понимает БД и ее проги тянут все свои данные из 500 Мб XML, правда у нее этот файл read-only).
А когда возникает потребность написать Насдак, то в любом случае на таком проекте будут нормальные архитекторы, ДБДевы, клиентщики и т.д. И базы будут выполнять те вещи, которые быстрее и органичнее делаются на их стороне, а middle tier заниматься своим делом.
no subject
Вопрос в том, чем лучше хранить бизнес логику на аппликейшн сервере, чем на субд сервере. И так и этак получается сложности в отладке, апгрейде, деплойменте и растёт общая сложность проекта. Бизнес логику нужно хранить в коде и нигде больше.
Работаете? Ну-ну
Не надо забывать, что и о оптимизации запросов жабист - средний похапист имеет обычно самые дикие представления. Так как писать все писать ручками с bdb надоедает удивительно быстро, я легко могу себе представить тот ужас, который будет создан. Так что увы - оптимизатор БД обычно много умнее среднего и тем более слабого разработчика, и сильнее расслабленного хорошего.
Мне, признаться, эта затея кажется в высшей степени бесперспективной, хотя веселья будет предостаточно. Как говорил К.Прутков "Некоторые вещи нам непонятны не потому, что наши понятия об этих вещах слабы, но потому, что вещи сии не входят в круг наших понятий".
Re: Работаете? Ну-ну
Ну да. Жабистам, которые не в курсе, например, так же не придет в голову выполнять оптимизацию кода вручную за Java-компилятор и JVM:-) Просто достаточно выполнять довольно четкие правила с предсказуемым результатом, и иметь общее представление о том, как работает компилятор/JVM. Хотя, казалось бы, вот вам в руки JNI, и вперед...
Re: Работаете? Ну-ну
Нежабистам вообще неизмеримо лучше: их такие задачи не волнуют.
Впрочем, по основному вопросу, как я вижу, возражений нет. Консенсус достигнут, это радует.
Re: Работаете? Ну-ну
Re: Работаете? Ну-ну