Ссылки и ссылки в базах данных документов

Цель документно-ориентированных баз данных — уменьшить «несоответствие импеданса», то есть степень, в которой данные разделяются для соответствия какой-либо схеме базы данных от реальных объектов, находящихся в памяти во время выполнения. При использовании документа весь объект сериализуется на диск без необходимости разбивать его по нескольким таблицам и снова соединять их вместе при извлечении.

При этом связанный документ — это то же самое, что и ссылочный документ. Это просто два способа сказать одно и то же. То, как эти ссылки разрешаются во время запроса, варьируется от одной реализации базы данных к другой.

При этом встроенный документ — это просто акт сохранения типа объекта, который каким-то образом связан с родительским типом внутри родителя. Например, у меня есть класс следующим образом:

class User
{
    string Name
    List<Achievement> Achievements
}

Где Achievement — произвольный класс (его содержимое не имеет значения для данного примера).

Если бы мне нужно было сохранить это с помощью связанных документов, я бы сохранил User в коллекции «Пользователи» и Achievement в коллекции «Достижения», при этом список достижений для пользователя является ссылкой на Achievement объектов в коллекции «Достижения». Для этого требуется, чтобы какая-то процедура соединения выполнялась в самом механизме базы данных. Однако, если вы используете встроенные документы, вы просто сохраните User в коллекции пользователей, где достижения находятся внутри документа User.

Представление JSON данных для встроенного документа будет выглядеть (примерно) так:

{
    "name":"John Q Taxpayer",
    "achievements":
        [
            {
                "name":"High Score",
                "point":10000
            },
            {
                "name":"Low Score",
                "point":-10000
            }
        ]
}

Принимая во внимание, что связанный документ может выглядеть примерно так: { "name": "John Q Taxpayer", "achievements": [ "somelink1", "somelink2" ] }

Внутри коллекции достижений { "somelink1": { "name": "High Score", "point": 10000 } "somelink2": { "name": "High Score", "point": 10000 } }

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

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

Вы можете прочитать о несоответствии импеданса здесь: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

ОБНОВЛЕНИЕ

Я должен добавить, что выбор правильной базы данных для реализации ваших нужд очень важен с самого начала. Если у вас есть много вопросов о каждой базе данных, возможно, имеет смысл связаться с каждым поставщиком и получить некоторые из их учебных материалов. MongoDB предлагает 2 бесплатных курса, которые вы можете пройти, чтобы узнать больше об их продукте и лучшем использовании в Университете MongoDB. OrientDB предлагает обучение, однако оно платное. Возможно, лучше попытаться связаться с ними напрямую и пройти какое-то предпродажное обучение (если вы хотите получить лицензию на базу данных), обычно они свяжут вас с каким-то консультантом по предпродажам, чтобы помочь вам оценить их продукт. .

MongoDB работает как RDBMS, где идентификатор объекта подобен внешнему ключу. Это означает, что «JOIN» требует больших затрат во время выполнения. OrientDB вместо этого имеет прямые ссылки, которые создаются только один раз и имеют очень низкую стоимость во время выполнения.