Комментарии 56
MySQL для PHP-приложений
MSSQL для C#, а Oracle для JavaScript :)
самая лучшая sql база - sqlite, идеальная для мелких вещей, скриптов и так далее, что не планируется сильно масштабироваться.
Поддерживаю. У меня в неё складываются результаты измерений в одной управляющей плате, делающей одну глупую железку - умной.
И ещё одно локальное веб-приложение на ней бегает.
Удобно, разворачивать намного проще, чем клиент-серверные СУБД.
Вы подразумеваете, что если не укладываешься в sqlite по размеру, то современным верным решением будет отказаться от SQL в пользу чего-то нового?
Я подразумеваю, что идея sqlite - божественна, ибо не требует запуска отдельного сервиса-базы-данных, чем сейчас страдает множество людей, когда для хранения пары килобайт данных запускают отдельную базу, для нее ставят докер, для него ставят какой-нить оркестратор и считают что они сэкономили на настройке инфраструктуры, потому что она занимает пару строк в хелм чарте.
А под капотом потрачено дохрена лишних мегабайт и гигабайт данных как в оперативке, так и на диске.
Вместо пары килобайт .cvs или .db sqlite файла.
p.s. я отлично понимаю, что доступ к файлу лочит файл, и в случае масштабируемости, это не то. Я именно про простые вещи, которые усложнятели превращают в бред
С какого количества МБ нужно начинать задумываться о смене sqlite?
Тут скорее надо задавать вопрос о конкурентном доступе на запись - у sqlite с этим в силу архитектуры не может быть хорошо. Но для ситуации - "1 клиент в 1 базу данных" sqlite перебить чем-то сложно
С какого количества МБ нужно начинать задумываться о смене sqlite?
Я думаю где-то в районе лимита максимального размера файла для вашей файловой системы.
Дело же не в размере базы данных, а в том что и кто с ней делает.
Если нужно параллельный доступ нескольким процессом, то сразу.
Если перформанс - не факт, что просто смена одной базы на другую возьмет и перформанс поменяет само по себе. sqlite вполне себе быстрый.
Вот то, что другую базу, со своим сервером можно поставить на другую машину - это простой способ распределить нагрузку на CPU/memory, но это очевидно.
Я подразумеваю, что идея sqlite — божественна
Ну да, sqlite — это хорошее современное воплощение хорошей старой идеи. Самой идее-то — лет 30, как минимум. В первой половине 90-х на ПК были широко распространены встраиваемые прямо в приложение файловые базы данных на реляционной основе (то есть, сделанные из таблиц и индексов) — dBase+Clipper, Paradox и пр… И NoSQL — с сетевой моделью данных, сейчас бы ее отнесли, наверное, к графовым — БД тоже была: dbVista, переименованная впоследствии в Raima Database Manager. И библиотеки для работы с файлами формата таких БД тоже были: CodeBase — для работы из C с форматом dBase и Clipper (этой сам активно пользовался), потом — IDAPI, она же — BDE (Borland Database Engine), которая могла работать и с файловыми форматами БД (Paradox и dbBase), и с SQL-серверами. С SQL, правда, было бедно: на ПК для него памяти было откровенно мало (особенно в DOS), потому все больше пользовались навигационным доступом (это — к отдельным таблицам, по одной записи, можно искать по индексу), но где-то во второй половине 90-х SQL стал вполне поддерживаться: в частности (из того, чем я пользовался сам), прикрутили SQL к BDE в качестве встроенного в него самого.
Ну, и сейчас SQLite — не единственная встроенная БД. Есть, как минимум, Embedded MS SQL — он используется для разработки, но вот разрешает ли MS его использовать для программ на ПК — это я не в курсе.
PS А ещё где-то мимо меня прошел MS Access: к нему тоже можно было обращаться из программ через ODBC или OLEDB/ADO, но с ним я никогда в таком режиме не работал.
В первой половине 90-х
В РФ — и во второй. На Clipper 5.x я писал всякие ARM до 2000 года. Особенно весело было аврально переписывать с Summer '87 на 5.x из-за двойной ошибки Y2K (кроме 2-значных дат, в S'87 просто не существовало 29 февраля). А потом навсегда ушёл из программирования.
dBase+Clipper, Paradox
FoxPro ещё забыли.
В РФ — и во второй. На Clipper 5.x я писал всякие ARM до 2000 года.
IMHO - не показатель: кто-то где-то до 2000 года программы на COBOL, например, поддерживал. А так во второй половине Windows стала массовой и в РФ тоже, и для нее уже была Delphi + IDAPI: поддерживались локальные/файл-серверные форматы dBase, Paradox и прочие. А в 1998 в самом начале лично я познакомился с Interbase (это SQL-сервер), но на самом деле он появился примерно тогда же, когда и Delphi, и тоже был доступен через IDAPI.
FoxPro ещё забыли.
И Clarion - тоже: нельзя объять необъятное.
А в 1998 в самом начале лично я познакомился с Interbase (это SQL-сервер), но на самом деле он появился примерно тогда же, когда и Delphi
Interbase? Намного раньше, это одна из самых древнючих СУБД на рынке, она в начале 1980-х появилась. Просто до Борланда попутешествовала между компаниями-владельцами, и пару раз имена меняла. Собственно, расширение её баз данных, .gdb, как бы намекает на истоки - Groton Database.
Появилось - в смысле на ПК. Был к дистрибутиву старшей версии Delphi приложен.
А так-то и по номеру версии - 4 -видно было, что это что-то не новое, и по архитектуре (один процесс на подключение) тоже было видно, что он изначально под какую-то ОС для мини-ЭВМ (Unix и т.п.) делался. Но историей я тогда не интересовался, да и непросто было ей интересоваться, без Интернета-то.
Ровно до тех пор, пока не появляется необходимость обращаться к ней из двух процессов одновременно (скажем, по крону и по запросу пользователя). Сценарий, увы, не такой уж редкий - даже в малых проектах.
Это вполне работает, если использовать WAL, в крайнем случае можно сделать самому через процесс-координатор
Ну придется развернуть в Minikube какую-нибудь систему очередей RabbitMicro или NanoKafka.
Это ирония и стёб если что. SQLite чисто для десктоп или мобайл приложений, не больше
Ирония в том, что изначально SQLite разрабатывалась для весьма серьезных задач, для управления конфигурацией эскадренных миноносцев.
Для случаев, когда запись редка, особенно конкурентная, а чтений много и объем данных относительно небольшой, SQLite неплохо справляется. Например, для каких-нибудь развесистых конфигов.
Это ирония и стёб если что. SQLite чисто для десктоп или мобайл приложений, не больше
Вы видимо плохо представляете себе варианты использования и ваше понимание "очень серьезных приложений" не совсем верное.
А что не так? Вполне себе работал с sqlite базами одновременно из нескольких процессов. Ограничение одно - пишущий лочит всю базу, остальным приходится ждать в очереди. При небольшом количестве записей это не критично. А если все процессы локальные, то при wal ещё и читатели не мешают писать, в rollback режиме журнала сложнее - писателю приходится ждать, пока старые читатели почитают, новым читателям ждать, пока писатель допишет.
Ну, значит у меня руки кривые. Что вполне правдоподобно. =)
Но опять же, имхо, начиная с определённого порога сложности координации проще будет плюнуть и взять готовый SQL сервер, который уже умеет решать эти задачи.
Вся суть sqlite это простота использования для простых задач.
Да, с определенного порога сложности, нужно брать отдельную базу.
Но если это не нужно, то при невероятно простой интеграции ты получаешь весьма мощный инструмент, и делает sqlite выдающимся на фоне других похожих решений.
Потому что конкуренты sqlite это не mysql/postgres/oracle/etc..
а csv, json, xml, plain text...
Какой-то странный у автора взгляд. SQL != RDBMS уж тыщу лет как, и даже NoSQL хранилища мутировали в NewSQL.
Эх, жаль оригинал за пэйволом, а то б неплохо было потыкать его на предмет а чё ж он сказать-то хотел.
Тоже не понял. Тезис "я видел плохо спроектированные бд, поэтому они зло" как то слабоват и тем более не увидел ответа, почему же смена типа базы данных от этого избавит.
Nosql – это ж не "no sql", а "not only sql".
Согласен! Раньше все гордились отсутсвием SQL в очередной базе данных, но рынок и предпочтения разработчиков расставили все по местам. Декларативность VS Императивность запросов, стоимость поддержки кода запросов/разработки новой функциональности в проекте, количества людей на рынке с нужными знаниями.
За годы работы я испробовал практически все РСУБД, а их попадалось мне немало
Просто наблюдение: если в первых же строках статьи есть упоминание о долгой кропотливой работе, то 99%, что наверху стоит плашка "Перевод". Хм.
Очень спорная статья.
И не все SQL одинаковы
В типа, все NoSQL одинаковы и совместимы друг с другом. Бред.
Не понял кол-во процентов в первой табличкиюе распространения БД. Там какие цифры по Y внизу и вверху?
Про заказнын БД - дорогая поддержка "после официальной поддержи", это верно вообще для любых заказных решений. БД тут вовсе не исключение, а правило.
Мало кто мог мог правильно проектировать крупные сложные системы на десятилетия. Никак не связано в БД.
Можно бесконечно цитировать сообщения СМИ о том, как реляционные базы данных разрушили бизнес
Можно так же бесконечно цитировать сбои по любым другим причинам.
и теперь мы платим сущие копейки за гигабайты хранилища и время работы процессора. Теперь процессор – не просто фиксированный актив, которому простительно работать вхолостую. Это ценный ресурс
Противоречие внутри одной мысли (левый перевод?) в начале - копейки за время CPU, а сразу следом - ценный ресурс.
Итого - теперь разных БД много и для каждой задачи лучше какая-то БД из множества предложений.
Мне кажется, что автор скорее критикует монолит, чем базы за ним.
Отдельная история, что говоря о новомодных базах, автор опускает тему надежности.
"Реляционные системы управления базами данных" =))) Прям с самого начала не задался перевод. Это БД реляционные, а не системы управления.
Странно, а я часто видел аббревиатуру РСУБД
В оригинале это "relational database management system". Но Вы правы
Довольно часто пишут странную, но устоявшуюся конструкцию "Реляционная СУБД (или РСУБД) - система управления реляционными БД".
Вот даже у MS
Что такое система управления реляционной базой данных? | Microsoft Azure
"Что такое реляционная система управления базами данных?
Системы управления реляционных баз данных помогают управлять данными масштабируемым способом."
Опять же смотришь статью на английском, там будет "An object–relational database (ORD), or object–relational database management system (ORDBMS)", а на русском будет перевод в лоб "Объектно-реляционная СУБД".
Бесит =)
Проблема реляционных баз данных - плохая горизонтальная масштабируемость и дороговизна. Такие монолиты-комбайны, когда все в одном и работает на сервере-мэйнфрейме.
Собственно поэтому и возник NoSql, как решение проблемы, со своими ограничениями (CAP теорема). Пример - MongoDB который хорошо работал с большими объемами данных.
Потом появились системы которые закрывали задачи, например по обработке данных в памяти, In-memory базы данных, для решения задач кэширования данных, Redis.
Для полнотекстового поиска ElasticSearch, и его конкуренты. Для аналитической обработки ClickHouse, для обмена сообщений RabbitMQ и Kafka. Это все NoSql и есть, но не в части хранения данных, а их обработки. Произошел такой распил монолита функциональности классических RDMBS.
Сейчас видно что архитектурно RDBMS из топа списка не могут предложить масштабируемую конфигурацию за вменяемые деньги. Появляются системы NewSql, YaDb как пример - заявляет поддержку транзакций, аналитической и потоковой обработки и это все на commodity hardware с горизонтальной масштабируемостью.
ИМХО на начальном этапе развития большинства проектов реляционные базы - решение по умолчанию в силу универсальности и распространённости. дальше уже можно искать пути оптимизации, если надо. а сложная бизнес-логика + десятилетия легаси без рефакторинга создадут проблемы хоть с реляционной базой, хоть с чем угодно.
В общем, гвозди надо забивать молотком, а вытаскивать клещами, и никак не наоборот. Да, согласен. :-)
Какой-то набор лозунгов на пол статьи. Все плохо, потому что плохо. Поэтому давайте так не делать.
В итоге:
Если кто-то сделал из базы single point of failure - дело не во внутренностях базы. Просто так сделали :)
Если кто-то не может неделю поменять что-то в базе - проблема скорее в долгой истории, и отчасти в ДНК конкретных людей
блокчейн спасет мир "транзакций", при этом упор не на транзакционность (я допускаю, что автор просто увлекся и забыл не мгновение, что такое транзакция), а на проверяемость.
В реале же, каждой базе свою нишу и назначение. Да, сейчас есть много вариантов и это круто. Очень много. Облака дают возможность реально каждому сервису выдать наилучшую БД, в теории.
На практике все проще.
Многие задачи не настолько эпичны, чтобы реально париться границами возможного для отдельно взятой платформы. Я б даже сказал - почти все.
Для многих задач точно важно время и стоимость разработки решения, а тащить в проект кучу технологий только потому, что она в теории лучше где-то там - значит потратить кучу времени, чтобы научить людей с ними работать. Я прям себе представляю, мы начинаем что-то писать, и тут я говорю - у нас будет 5 разных баз. Команда может не понять и собравшись на сходку, вернуться с "черной" меткой :)
Многие узкоспециализированные базы на то и узко-специализированные, а потому смотри предыдущие пункты
---------------
То, что реально важно:
стоимость, и только в случае, если реально разница существенна. Рубиться за 10 ... 100 ... (возможно) 1000 долларов в месяц - вообще не имеет смысла
минимизация зоопарка, так как накладные расходы на его поддержку будут точно велики
---------------
По статье, мне кажется автор взял слишком серьезный фокус "реляционные базы - отстой", хотя в реале просто есть много нишевых альтернатив
Боже мой, какой феерический поток бредовых мыслей.
Вот тоже - читал, и с самого начала никак не мог отделаться от мысли "Ну что за бред!". По стилю и даже по содержанию то ли заказуха, то ли просто для "плюсадин" в публикации. Подходящее? берём. Не подходящее? не упоминаем. Более-менее подходящее? описываем только то, что подходит. Вообще не по делу, но похожее? притянем за уши, авось не оторвутся.
Имхо не надо было переводить.. не стоило оно того.
В первую очередь для хранения данных следует выбирать из основных вариантов key-value, таких как приложения Apache Cassandra, AWS DynamoDB, Google Cloud Spanner или Azure Cosmos DB. Они легко масштабируются, долговечны ...
Из 4х баз приведены 3 облачные базы.
Облачные базы и долговечность противоречат друг-другу.
Долговечность требует предсказуемость и полный контроль.
А когда cloud provider deprecate services (Google), то в здравом уме я не построю продукт, основанный на облачных базах.
Реляционные системы управления базами данных становятся проблемой. Что с этим делать?
Перестать писать идиотские заголовки и понять, что для каждой задачи нужен свой инструмент.
Если для каких-то задач РСУБД подходят не очень, это не значит, что они являются проблемой.
"База данных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ)[5]"
База данных — Википедия (wikipedia.org)
Не подходит вам реляционная модель данных и ради Бога. Вот вам файловая система, википедия и миллион других способов организовать данные. Вы главное определитесь для чего. Что мы должны получить, за какое время, какие требования к хранению и т.д. и т.п. Самая популярная БД это Excel, наверное до сих пор. С сомнительной реляционностью. Вставил картинку в таблицу и вот тебе уже объектно-ориентированный nosql =)
Git, кстати, хорошая БД для своих целей.
Поскольку специалисты по базам данных из 80-х ушли на пенсию еще несколько десятилетий назад, большинство из созданных ими на заказ систем так и живут, управляемые SQL-приложениями, которые в массе своей уже не поддерживаются. Для многих крупных организаций эти приложения превратились в эдакие «черные ящики».
Т.е. автор хочет сказать, что проблема РСУБД - в высокой надёжности и квалификации разработчиков? Такой, что построенное может работать десятилетиями без вмешательства человека вообще?!
И это РСУБД захватили руководство компанией и разработали процедуру увольнения сотрудников без какой-либо их замены? Слава роботам реляционным базам данных!
>Среднестатистический разработчик будет шокирован этим заявлением. А для опытных инженеров баз данных считается нормой прятать всю структуру БД за представлениями и хранимыми процедурами.
Это зависит не от способностей разработчика. Есть бигтех и есть все остальное. Во всем остальном нет таких вакансий как разработчик БД, а в бигтех тебе даже простой селект запрос помимо хранимых функций не дадут вкорячить, не спустив по регламенту через отдел БДшников и не получив аппрув.
Добиться плохой работы приложения на Oracle или Postgres при грамотной инфраструктуре довольно сложно. Как правило проблемы начинаются на аналитических запросах при паре терабайт записи на таблицу в месяц. Тогда берут другой тип БД, который заточен на чтение, и может даже не иметь update функционала в себе, т.к. это вызовет тяжёлые процедуры перестроения индекса, и подключают готовые CDC решения к журналу. SQL прекрасен и для большинства ситуаций его с избытком. Проблема проявляется исключительно при гигантских объемах генерируемых пользователями данных. А так даже огромный маркетплейс уютно будет себя чувствовать с SQL решениями.
Ой, а у нас свалила команда, разрабатывавшая микросервис по расчёту бонусов. Они использовали потрясающие современные средства: язык малбогл, перпендикулярно-ориентированную ropesoapdb и протокол nanobin с патчами от beegle&bugle. Всё так здорово, что полтора года не можем найти новую команду с этими компетенциями.
Рекомендую по теме статью «Вьетная компьютерной науки, Тед Ньюард, 2006».
Получается что даже с появлением NoSQL глобально ничего не изменилось и РСУБД продолжают доминировать. Думаю что в ближайшие 20 лет тоже мало что изменится, потому что архитектура РСУБД гораздо ближе к архитектуре ЭВМ
Рекомендую по теме статью «Вьетная компьютерной науки, Тед Ньюард, 2006».
Получается что даже с появлением NoSQL глобально ничего не изменилось и РСУБД продолжают доминировать. Думаю что в ближайшие 20 лет тоже мало что изменится, потому что архитектура РСУБД гораздо ближе к архитектуре ЭВМ
Все проблемы, описанные автором, решаются грамотной индексацией в реляционке
Согласен с некоторыми комментариями, что заголовок несколько не точен в текущих реалиях.
Если отделить мух от котлет, то существует проблема легаси и проблема ограничений масштабируемости и распределенности (так сказать, архитектурных ограничений).
Эти проблемы существуют вне зависимости от РСУБД.
По поводу первого: любого монстра, разработанного в 80 - 90 -ые сопровождать очень дорого, а масштабировать и подавно. Это связано с целой кипой проблем - не только с устаревшими технологиями, но и со сложной логикой (представьте, эта логика накидывалась слой за слоем поколениями разработчиков, которые ни чего не знали про банду 4х))), Большим объемом накопленного информационного мусора, бюрократией, наконец.
По второму, хоть и есть решения для РСУБД по горизонтальному масштабированию, конечно, в силу ключевых особенностей этих БД, они не лучшие представители в этой категории. Но, РСУБД сильны в другом.
Так что, я бы сказал, что РСУБД постепенно превращаются из всемогущего, почти безальтернативного инструмента, в нишевое решение, хотя, пока эта ниша и самая большая в применении, но имеет тенденцию сужаться.
Вместе с появлением ООП где-то на заре, появился и вопрос зачем тратить врем и ресурсы на сборку объектов в памяти из реляционных баз? Не проще ли хранить в базе сразу объекты, например, классы Java со всеми полями и методами в memory likre model. Оказалось таки да, и проще, и быстрее и удобнее.
15 лет используем в своих проектах Versant Object Database (она же Actian NoSQL Object Database). Да, стоит дорого, работает сильно быстрее реляционных и еще важно то, что разработка идет в разы быстрее, чем на РСУБД. Написал про это статью - Versant Object Database — объектная СУБД родом из Гамбурга
Работу с РСУБД редко, но вспоминаем, как страшный сон.
Ваше суждение излишне безапелляционно (IMHO)
Вместе с появлением ООП где-то на заре
По-моему, вы не слишком осведомлены в истории появления ООП. "На заре" - это лет сорок назад, по крайней мере первый язык ООП- Smalltalk - был упомянут ещё в статье про Настоящих Программистов (тех самых, которые не используют Паскаль), вышедшей уже более 40 лет тому назад.
Не проще ли хранить в базе сразу объекты, например, классы Java со всеми полями и методами в memory likre model
Хранить-то можно что угодно - вопрос как с этим работать.
Например, что делать, когда потребуется поиск/фильтрация/сортировка по полям? Ответ известен - создавать индекс, но индексировать поля однородных записей в таблицах значительно проще и эффективнее, чем поля объектов произвольной, возможно - сложной, структуры.
Или - как хранить объекты, являющииеся полями других объектов? Если - как части объектов, в которые они входят, то получается денормализованная структура, со всем присущими ей аномалиями - обновления и т.д. Ели как ссылки на вложенные объекты - то как поддерживать эти ссылки. И т.д.
Если для вашего проекта объектная БД подходит - используйте. Но это решение - тоже не универсальное. Как и противоположное - не использовать в сколь-нибудь сложных проектах объекты вообще, даже в коде: видел и такое в комментариях ув. @SpiderEkbк недавней статье, вызванных его опытом работы с высокнагруженным ядром банковской системы крупного банка. Даже в коде, в памяти - а уж использовать в таких проектахобъектных хранилищ данных, и тянуть, фигурально выражаясь, когда нужен только банан, ещё и обезьяну, которая его держит, и джунгли, где обезьяна живет - это вообще за всякие рамки входит.
Короче мое мнение: всякое решение имеет ограниченную область применения. И подобрать решение для конкретной задачи - это уже отдельное умение. Использовать для этого такие грубые шаблоны, как вы тут пишете - это неуместно.
Спасибо за упоминание :-) Польщен :-)
индексировать поля однородных записей в таблицах значительно проще и эффективнее, чем поля объектов произвольной, возможно - сложной, структуры
Да. Опять же, из личного опыта. Если таблица содержит достаточное количество записей (ну вот тут недавно обсуждали - 400 000 000 записей - это много или мало, сошлись на том, что в целом терпимо - теоретический предел для нашей БД ~4 000 000 000, дальше уже требуется партициониование) и при этом активно используется на изменение (ну, скажем, 100 000 000 изменений в сутки), то даже самый простой индекс уже дает ощутимый вклад в загрузку системы. Именно поэтому у нас не используются join logical files, хотя язык описания - DDS - в нашей системе такое позволяет:
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
A* Joins fields from two physical files into one record format
A R RECORD1 JFILE(PF1 PF2)
A J JOIN(PF1 PF2)
A JFLD(NAME NAME)
A NAME JREF(1)
A ADDR
A PHONE
AТут два "физических файла" PF1 и PF2 объединены по полям PF1.NAME = PF2.NAME
Но такие штуки достаточно сильно грузят систему.
И делать лишний индекс на большие таблицы с высокой плотностью изменений - это нужно отдельно согласовывать и очень серьезно обосновать что овчинка стоит выделки.
И вы совершенно точно подметили:
тянуть, фигурально выражаясь, когда нужен только банан, ещё и обезьяну, которая его держит, и джунгли, где обезьяна живет - это вообще за всякие рамки входит
И это при том, что наш основной язык нативно поддерживает все типы данных, что есть в БД - char, varchar, decimal, numeric, date, time, timestamp, не требуя для работы с ними создания дополнительных объектов или каких-либо преобразований - просто прочитали запись из БД в структуру и сразу с ней (с ее полями) работаем, без необходимости оборачивать куски байтового буфера в объекты.
Я начал программировать в 1986 году, в 6 классе средней школы. 7 часов информатики в неделю. В школе стояла ЕС1030, PL/1, ЯУЗ, все дела. Соглаcен, что "Заря ООП" где то лет 40 назад, если не раньше. Я перешел на ООП видимо поздно, где-то в 1999, на Java 1. Versant Object Database мы используем с 2007. Вот библиотека, собравшаяся за годы.
Про создавать индексы в таблицах удобнее - это не так. В VOD с этим все хорошо.
VOD, как пишет производитель, для экстремально сложных, взаимосвязанных данных, причем там, где их надо очень быстро использовать, в режиме реального времени, например, в процессинге. Если бы вы "покурили" документацию, то вам стало бы понятно, как там здорово и круто устроено. Но, чтобы не углубляться, можно почитать о практике использования. Да и понятно, что в нынешних условиях, например, вот это препятствует ее широкому применению у нас. Так что я не продавец VOD, и не настаиваю )
Серебрянной пули нет, да, согласен. Я написал об этом в вышеупомянутой статье. Также за 15 лет я привык к некоторому уровню агрессии со стороны поклонников РСУБД, защищающих свою поляну, и, объективно, не разбирающихся в true-объектных СУБД. Ну, се ля ви так сказать.
VOD стоит дорого, где-то 15К USD за ядро. Actian не дает документацию к VOD просто так, но добрые люди из Pennsylvania State University выложили один том "Versant Object Database Fundamentals Manual" . Можно ознакомиться, если интересно
Реляционные системы управления базами данных становятся проблемой. Что с этим делать?