Самая большая проблема, которую я видел, - это отсутствие стандартизации. В мире RDBMS вы можете продвинуться далеко вперед с любой случайной базой данных, если знаете SQL. Они в основном все это реализуют, с небольшими изменениями. Я не знаю ни одной существующей СУБД, которая не поддерживает SQL: вы можете почти взаимозаменяемо использовать «СУРБД» и «SQL».
Ближайшая вещь для OODBMS - это, возможно, OQL, который был полным провалом.
Ни одна база данных никогда не реализовывала большую ее часть. Я использовал довольно хорошую коммерческую OODBMS пару лет назад, но (по состоянию на 2007 год или около того, и это было на основной версии 8 или 9), он даже не поддерживал запросы к объекту по его имени. В руководстве просто сказано, что до этой части OQL они еще не дошли. (Я не уверен, но вы могли бы сделать это в нативном вызове).
Большинство объектных баз данных, которые я видел недавно, имеют интерфейсы на родном языке, а не язык запросов, такой как OQL. Система, которую я использовал, например, поддерживала (только!) Perl и VB, IIRC. Ограничение вашей аудитории только парой языков (или принуждение их писать обертки, как мы это делали) не способ завоевать друзей.
Из-за этого нет конкуренции и, следовательно, нет простого плана резервного копирования. Если вы поместите свои данные в MS-SQL, и Microsoft перестанет их поддерживать, вы, вероятно, сможете сбросить свои данные в Postgres и перенести свои запросы без особых проблем. (Это может быть много работы, если у вас много запросов, но я не сомневаюсь, что вы могли бы сделать это. Это боль, но технически не сложно.) Или Oracle, или MySQL, или многие другие, оба коммерческие и бесплатно.
С OODBMS такого не существует: если тот, который вы используете, обанкротился, или он идет в направлении, которое вам не полезно, или вам не хватает ключевой функции, которая вам нужна, вы можете ' просто скопируйте ваши данные в конкурирующую OODBMS и перенесите ваши запросы. Вместо этого вы говорите об изменении основной библиотеки и внесении значительных изменений в архитектуру. На самом деле, вы ограничены коммерческой OODBMS, которой вы действительно доверяете (вы можете назвать хотя бы одну?), Или OODBMS с открытым исходным кодом, которой вы доверяете свою команду, чтобы поддерживать ее, когда дела идут плохо.
Если это звучит как FUD, извините, я не собирался этого делать. Но я был там, и с точки зрения управления проектами я не решался бы вернуться, хотя среда программирования может быть прекрасной. Еще один способ думать об этом: посмотрите, насколько популярно функциональное программирование сегодня, несмотря на то, что это хорошая идея. OODBMS такие же, но хуже, так как это не просто ваш код, но ваш код и ваши данные. Я бы с удовольствием начал сегодня крупный проект в Эрланге, но все же не решался бы использовать OODBMS.
Поставщики OODBMS: чтобы изменить это, вам нужно , чтобы было проще оставить вас для ваших конкурентов . Вы могли бы выкопать OQL и фактически реализовать это, или сделать это на уровне API, как ODBC, или как угодно. Даже стандартный формат дампа (использующий JSON?) И инструменты для импорта / экспорта в / из этого для нескольких OODBMS, были бы отличным началом.