Концепция OODBMS довольно разрушена, и различные коммерческие и бесплатные предложения, появившиеся за последние несколько десятилетий, едва заметили на рынке.
Реляционная модель является более мощной, чем объектные модели, с точки зрения видов вопросов, которые вы можете задать своим данным. К сожалению, SQL отбросил большую часть выразительных возможностей, на которые способна реляционная модель, но даже в этой разбавленной форме все еще проще выражать запросы в SQL, чем в обычной базе данных OO (будь то ORM или OODBMS).
Запросы в OODBMS в основном выполняются навигационными операторами, а это означает, что если в вашей базе данных по продажам есть продавцы, владеющие своими продажами, то запросы о ежемесячных продажах для определенного SKU будут не только крайне медленными, но и очень неудобными. выражать. Рассмотрим также модель безопасности, которая предоставляет сотрудникам доступ к зданиям. Какой правильный способ выразить это? Должны ли сотрудники иметь набор зданий, к которым у них есть доступ, или здания должны содержать набор сотрудников, которые имеют к ним доступ? Более конкретно, почему один класс должен иметь коллекцию другого, включенного в его дизайн? И какой бы вы ни выбрали, как бы вы спросили, какие пары сотрудников имеют более одного здания, к которому они могут получить доступ совместно? Не существует простой навигационной схемы, которая могла бы ответить на такой вопрос. Разумное решение - объект «Доступ» - это, по сути, возврат к правильно нормализованной реляционной схеме, и для этого требуется некоторый язык запросов, который в значительной степени заимствует из реляционной алгебры, чтобы ответить на вопрос без значительных перерасходов. проводная передача данных.
Также рассмотрим еще одну важную силу, о которой говорят в OODBMS: методы, особенно наследование виртуальными методами. Спортивная клиника может иметь разные показатели риска получения травмы для разных видов спортсменов. В мире ORM это будет автоматически выражаться в виде иерархии классов с Athlete в корне и виртуальным методом int InjuryRiskScore(), реализуемым каждым производным классом. Проблема заключается в том, что этот метод неизменно реализуется на клиенте, а не на бэкэнде, поэтому, если вы хотите найти 10 спортсменов с самым высоким риском по всем видам спорта в вашей клинике, единственный способ сделать это - собрать всех спортсменов через провод и передать их через очередь приоритетов на стороне клиента. Я также не знаком с миром OODBMS, но думаю, что возникает та же проблема, так как механизмы хранения обычно хранят достаточно данных для регидратации объектов на языке программирования клиента. В реляционной модели или SQL вы можете выразить оценку риска травмы как представление, которое может быть просто объединением представлений для каждого спортсмена. Тогда вы просто задаете вопрос. Или вы можете задать более сложные вопросы, такие как: «У кого был самый большой рост риска травм со времени проверки в прошлом месяце?» или даже «Какой показатель риска оказался лучшим предиктором травмы за последний год?». Самое главное, что на все эти вопросы можно получить ответы внутри СУБД, причем не более, чем вопрос и ответ, передаваемый по проводам.
Реляционная модель позволяет СУБД выражать знания с высокой степенью детализации на основе логики предикатов, которая позволяет объединять, прогнозировать, фильтровать, группировать, суммировать и иным образом преобразовывать различные измерения фактов, которые вы в них храните, полностью специальная манера Это позволяет вам легко составлять данные способами, которые не предполагались при первоначальном проектировании системы. Таким образом, реляционная модель допускает самое чистое выражение знаний, которое мы знаем. Короче говоря, реляционная модель содержит чистые факты - ни больше, ни меньше (и, конечно, не объекты или их прокси).
На историческом примечании реляционная модель возникла в ответ на катастрофическое состояние дел с существующими сетевыми и иерархическими СУБД того времени и в значительной степени (и справедливо) вытеснила их для всех, кроме небольшой ниши прикладных областей (и даже они, вероятно, остались в основном из-за того, что SQL не смог обеспечить питание RM). Глубоко иронично то, что большая часть индустрии сейчас тоскует по «старым добрым временам» теоретических сетевых баз данных, а это, по сути, то, к чему стремятся OODBMS и текущий набор баз данных NoSQL. Эти усилия справедливо критикуют SQL за его неспособность удовлетворить сегодняшние потребности, но, к сожалению, они предположили (ошибочно и, вероятно, из-за чистого невежества), что SQL является высокоточным выражением реляционной модели. Следовательно, они пренебрегали даже рассмотрением самой реляционной модели, которая практически не имеет ограничений, которые уводят многих от SQL, часто к OODBMS.