Как базы данных документов справляются с изменяющимися отношениями между объектами (или делают ли они вообще)?

Question

Скажем, в начале проекта я хочу сохранить коллекцию компаний, а внутри каждой компании - коллекцию сотрудников.

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

+ Customers[]
   +--Customer
      +--Employees[]
         +--Employee
         +--Employee
   +--Customer
      +--Employees[]
         +--Employee

Что произойдет, если в дальнейшем появится новое требование, чтобы некоторые сотрудники работали в нескольких компаниях?

Как можно управлять такого рода изменениями в базе данных документов?

Разве простота базы данных документов не станет вашим злейшим врагом, поскольку она создает хрупкие структуры данных, которые нелегко изменить?

В приведенном выше примере мне нужно было запустить сценарии изменения, чтобы создать новую коллекцию «Сотрудники», и переместить каждого сотрудника в эту коллекцию, сохраняя при этом какой-то ключ связи (например, CompanyID для каждого сотрудника).

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

В таком случае, я все еще использую базу данных документов, как и должно быть?

Разве это не становится больше похожим на реляционную базу данных?

Answer 1

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

Сказав все это, они ключом к использованию такой системы, как MongoDB, является моделирование ваших данных для соответствия MongoDB.То, что у вас есть выше, имеет полный смысл, если вы используете MySQL ... используя Mongo, у вас точно будут проблемы, если вы структурируете свои данные, как будто это реляционная база данных.

Если у вас есть Employees, кто можетработать на одном или нескольких Companies, я бы структурировал его следующим образом:

// company records
{ _id: 12345, name : 'Apple' }
{ _id: 55555, name : 'Pixar' }
{ _id: 67890, name : 'Microsoft' }

// employees
{ _id : ObjectId('abc123'), name : "Steve Jobs", companies : [ 12345, 55555 ] }
{ _id : ObjectId('abc456'), name : "Steve Ballmer", companies : [ 67890 ] }

Вы бы добавили индекс на employees.companies, что позволило бы очень быстро получить всех сотрудников, которые работают наданная компания ... независимо от того, сколько компаний они работают.Ведение краткого списка компаний на одного сотрудника будет намного проще, чем ведение большого списка сотрудников для компании.Чтобы получить все данные для компании и всех ее сотрудников, нужно выполнить два (быстрых) запроса.

Разве простота базы данных документов не станет вашим худшим врагом, поскольку она создает хрупкие данныеструктуры, которые не могут быть легко изменены?

Простота может вас укусить, но очень легко обновить и изменить позже.Вы можете создавать сценарии изменений через Javascript и запускать их через оболочку Mongo.

Answer 2

Мой недавний ответ на этот вопрос охватывает это в контексте RavenDb:

Как бы я смоделировал данные, которые являются иерархическими и реляционными в системе документов-ориентированной базы данных, такой как RavenDB?