Объектно-ориентированные базы данных

Не нужно делать из СУБД ОО-культа. Это просто утонченная разновидность стореджа. С языком запросов.

Периодически возникает ОО-эпидемия для СУБД, но быстро само-исцеляется.

Для большинства задач достаточно SQLite/Postgresql/MariaDB/Redis/Couchdb/Memcached

По поводу того, что есть, можно глянуть табличку в Wikipedia.

Заметный выигрыш ООСУБД дают в предметных областях, где используются сложные модели данных. Например, при реализации хранилищ информации в САПР системах. Входят ли такие предметные области в ваше понятие «продакшен» — без понятия.

Для большинства задач достаточно SQLite/Postgresql/MariaDB/Redis/Couchdb/Memcached

SQLite

Как ты сложную структуру туда засунешь? Когда одно поле одной записи должно содержать неопределенное количество сложных объектов?

Честно признаюсь - я нуб в базах данных, и мой быдло-подход это совать всё в одну строку с разделителями \n \t / и просто пробелами. Не похоже чтобы это быстро работало (парсинг строк ведь), а альтернатива - создать невероятную кучу таблиц что мне не нра.

Я так понимаю ТС хочет БД, поля которых могут хранить сложные объекты и структуры? Тогда и я присоединяюсь к поиску. Или я не верно понял?

Я так понимаю ТС хочет БД, поля которых могут хранить сложные объекты и структуры? Тогда и я присоединяюсь к поиску. Или я не верно понял?

Ты все верно понял. Я, собственно, даже читал про подобные БД, но они либо на жаве, либо совсем не развиваются. В ГИСах есть объектно-релляционные БД (таблицы + объекты), но не полностью ООП. Есть еще т.н. документориентированные БД, но не знаю, насколько они подходят под ООП. Цель данной темы, наверно, не столько найти решения, сколько найти людей, которые их используют в реальности. Может, мне с этим на спец. форумы по БД, но вдруг и здесь кто-то найдется.

ты таки хочешь хранить сложные структуры или еще и хранить поведение для каждой?

Хм. Если поведение это уже получается больше похоже на язык программирования. ) Скорее сами структуры. А что, есть мысли?

ну тогда документоориентированная бд подходит тебе. или рсубд с типами данных xml или (b)json и функциями для работы с ними.

JSON,XML

Если нужны именно запросы по полям, то смотрите в сторону поддержки JSON, то слон или диван

Если нужно хранить объекты в криокамере не задумываясь, то посмотрите в сторону сериализации питона или пыха, а также отличные возможности erlang с функцией term_to_binary

но вдруг и здесь кто-то найдется.

Это вряд ли.

Да и ООСУБД пережили свой пик популярности в середине 90-х. Но потом выяснилось, что областей, где ООСУБД заруливают все остальное, совсем не много, а в остальных областях вполне справляются либо обычные РСУБД (через слой ORM), либо РСУБД с объектными расширениями. А потом еще и NoSQL добавился, куда сложные объекты в каком-то сериализованном виде запихивают (вроде JSON-а)... Так что и сейчас ООСУБД особо ловить нечего.

То, что большое количество реализаций ООСУБД ориентировано на managed-языки не удивительно. Вообще корни ООСУБД растут из SmallTalk-а, был небольшой период, когда было несколько ООСУБД с поддержкой C++ (Objectivity, Versant, POET), но появление Java и .NET сделала их менее актуальными.

Спасибо за обстоятельный и толковый комментарий.

Но потом выяснилось, что областей, где ООСУБД заруливают все остальное, совсем не много

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

db4o

ну вроде как тот же пггис вполне себе держит опенстритмап

а главное умеет нужные индексы для геоданных

А не могли бы вы уточнить что это за области

Я уже выше говорил, это области, где требуются сложные модели данных. В частности такие, для которых применима объектная декомпозиция. А уж где именно это может встретится — тут уж от конкретного разработчика зависит.

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

class Shape {
public :
  virtual void Draw() = 0;
  ...
};
class Circle : public Shape {...};
class Rectangle : public Shape {...};
class Group : public Shape {
  vector<Shape> items;
public :
  virtual void Draw() { foreach(i: items) i.Draw(); }
  ...
};

При этом вам не нужно думать о том, какие именно объекты лежат у вас в Group.items — там могут быть любые наследники Shape. Вы поднимаете из БД объект Group, а сама БД создает вам в памяти экземпляры нужных типов. И вы работаете с ними так, как будто они просто были у вас в памяти.

Аналогичный эффект дают и ORM над РСУБД или над РСУБД с объектно-реляционными расширениями, но за счет больших затрат на выборку и сохранение данных в БД.

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

Скажем, у вас в Group.items лежат 10K объектов разных типов и вы добавляете туда еще один. ООСУБД, скорее всего, сделает обновление значения items с минимальными накладными расходами. А вот если ваш Group лежит в виде json-а в какой-нибудь MongoDB, то вам может потребоваться создать новый json для всех значений из Group.items и лишь после этого сохранить весь новый json в БД.

Ну а уж применимы эти подходы в вашей предметной области — тут уж вам виднее должно быть.

есть подозрение что ООСУБД сперва просто сбросит информацию о изменениях в wal, потом сделает изменения в рабочей памяти и уже либо по запросу либо при шатдауне уже непосредственно произведет сериализацию объектов в постоянное хранилище.

т.е. по факту in memory db с возможностью сохранить данные в постоянном хранилище

А почему классические реляционные ДБ - не «объектно ориентированные»? Как это должно выглядеть? Чего ты ждешь от «объектно-ориентированных бд»?

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

В ГИСах есть объектно-релляционные БД

В ГИСах, насколько я себе представляю, PostgreSQL + PostGIS де-факто стандарт, если смотреть бесплатные решения. Если не бесплатные - ArcSDE и то, во что он превратился потом. В ГИСах важнее целостность данных + топологические ограничения (такой-то слой точек должен содержаться в таком-то слое полигонов и т.д.) и желательно соответствие стандартам OGC. PostGIS всё это покрывает.

Под ОО я так и не понял, что понимается. Из википедии я понял только, что связи делаются ссылками (а не как в реляционных базах, по общим столбцам) и отсутствие необходимости поддерживать и синхронизировать схему в бд и модель в программе. И чем в таком случае документориентированные не подходят.

Моя область связана с геоэкологией

Ориентироваться на бесплатный стэк ГИС (QGIS,PostGIS, MapServer/Geoserver если надо) думаю будет правильным решением. Под python (есть и другие языки, но документация на python) есть библиотеки GDAL, которые со всем этим могут работать.

Зачем объектная ориентированность, если есть Object-Relational Mapping? Тут конечно желательно СУБД, хорошо подстроенную под ORM, и это скорее SQLite (Desktop + Mobile) либо PostgreSQL (Server Backend), чем MySQL/MariaSQL.

P.S. Если хочется гиперудобства, то iOS + CoreData + MagicalRecord. Малопопулярные объетно-ориентированные СУБД выбирать не стоит, лучше уж ORM + SQLite (ormlite для Java, например) или ORM + PostgreSQL.

JSON,XML хорошо, но это ж тоже строки, не?