ModelRЛично мне хотелось бы знать, какими средствами автоматического обновления указателей и навигации обладают ООСУБД?

ИМХО основное отличие РБД от ОБД - в первой данные хранятся в таблицах, а во второй - в графе. Причем как таблицы, так и граф можно реализовать по разному, соответсвенно как разные реализации РБД так и ОБД могут иметь различные возможности. Пользователя ИМХО в первую очередь будут интересовать возможности модели представления данных. Во вторую очередь - скорость, надежность и прочие технические характеристики. Их можно вытягивать оптимизацией и различными реализациями одной и той же модели данных. Еще важен вопрос стандартизации. В области РБД она уже практически завершилась. А в ОБД все еще царит хаос первооткрывателей )))

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

mir Конечно же, в таком случае навигация в ОСУБД неизбежна, поскольку набор операция над графами, известный в математике, весьма специфичен и мало пригоден для задач управления данными. Это вынуждает довольно часто вместо декларативных указаний "ЧТО СДЕЛАТЬ", характерных для РСУБД, писать фактически инструкции для ОСУБД "КАК СДЕЛАТЬ". Это по сути и есть главный признак навигационного подхода. В РСУБД мы обычно говорим "приведи корабль туда-то" и все, а навигация выполняется автоматически.
Ваш тезис верен только в лабораторных условиях. В реальной жизни же в запросе приходится соединять десятки таблиц для получения результата. А JOIN является прямой аналогией навигации. И в этом случае РМД проигрывает ОБД из за наличия ограничений в модели данных и как следсвие - из за возростания колличества этих JOIN. Тоесть "автоматическая" навигация в РБД фактически приводит к усложнению запросов.

mirВ ОСУБД мы довольно часто (для сколько-нибудь нетривиальных случаев) вынуждены "брать штурвал в руки" и вести корабль по извилистым каналам.
В нетривиальных случаях в РСУБД приходится выруливать из лабиринтов JOIN между сотнями таблиц, наличие которых оправданно исключительно ограничениями реляционной модели.

Alexey RovdoВот ведь интересный вопрос: является ли на самом деле JOIN аналогом навигации? Смею утверждать, что ставить здесь знак эквивалентности не верно. Действительно, существуют частные случаи использования JOIN, которые во многом похожи на использование навигации, но в общем случае - JOIN не эквивалентен навигации.

Согласен, что формальной эквивалентности нет. Однако в общесмысловом плане прямая навигация очень близка к outer join

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

ModelRПравильно ли я понимаю, что те ОО системы, о которых вы говорите, оставляют все эти заботы за пользователем?

Буду говорить за свою ООБД.
Разумеется у пользователя забот с этим нет.

В апи входят средства по поддержке работы с деревьями, связями, узлами и прочим.

Так как база объектная, и объекты реализуются на C# для платформы .NET то деревья на основе parent-child связей пользователь может создовать из объектов собственных классов в том виде, который необходим для решения данной задачи.

Каждый объект имеет свой ID. После присвоения этого ID объекту этот ID не изменяется на протяжении жизни объекта. При этом запуск и остановка приложения или ядра БД на этот ID уже не влияет. Этот ID нужно считать указателем на объект, хотя на самом деле это не указатель а номер узла в дереве индексов. Дерево 3х уровневое, и поиск реального указателя на объект по его ID проводится за 3 операции выборки узла индекса.

При необходимости обратится к объекту напрямую, придется восспользоваться АПИ системы и получить указатель на конкретный экземпляр объекта по его ID. Сохранять же настоящие указатели в процессе десериализации объекта нельзя. Нужно сохранять его ID.

Например

В связи с этим, в моей реализации для .NET разработчик будет иметь некоторое неудобство. В место или дополнительно к реальным указателям на .NET объекты в Fields придется хранить и эти ID.

Если пользоваться АПИ для поддержки раскрашенного орграфа, то сериализация-десериализация объектов производится автоматически и разработчику обращать внимание на нее нет необходимости. Однако в этом случае будет нельзя иметь в классе поля которые сереализуются/десерелезуются в БД. В место полей в .NET классе будет необходимо хранить значения пропертей в аттрибутах узла дерева объектов (тот же апи AttachConnector(attributeID);

Итак, учитывая, что ID объекта не меняется все время жизни этого объекта, то СУБД нет необходимости модифицировать или корректировать указатели на другие объекты хранящиеся в экземплярах объектов.

Граф объектов управляется посредсвом АПИ. Рядовому разработчику лезть в детали реализации индексов, деревьев и узлов графа вовсе не обязательно. Тем более что вся низкоуровневая механика сделана на C а пользовательские объекты реализуются на C#