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

Question

Я понимаю, что JOINs невозможны или недоверчивы в документах. Я исхожу из реляционной базы данных и пытаюсь понять, как справляться с такими сценариями.

Предположим, у меня есть коллектив сотрудников, где я храню всю информацию, связанную с сотрудником. Ниже приведен типичный работник документа:

{ 
    "id": 1234, 
    "firstName": "John", 
    "lastName": "Smith", 
    "gender": "Male", 
    "dateOfBirth": "3/21/1967", 
    "emailAddresses":[ 
     { "email": "johnsmith@mydomain.com", "isPrimary": "true" }, 
     { "email": "jsmith@someotherdomain.com", "isPrimary": "false" } 
    ] 
} 

Давайте также сказать, у меня есть отдельная коллекция проектов, где будут храниться данные о проекте, который выглядит примерно так:

{ 
    "id": 444, 
    "projectName": "My Construction Project", 
    "projectType": "Construction", 
    "projectTeam":[ 
     { "_id": 2345, "position": "Engineer" }, 
     { "_id": 1234, "position": "Project Manager" } 
    ] 
} 

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

Это два отдельных запроса? Один для проектов, а другой для людей, чьи идентификаторы появляются в коллекции проектов?

Если да, то как мне вставлять данные о людях, то есть полных именах, адресах электронной почты? Затем я делаю цикл foreach в своем приложении для обновления данных?

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

Благодарим за помощь.

Answer 1

«... как я могу справиться с тем, чтобы я вернул всю соответствующую информацию о людях в команде, то есть полные имена, адреса электронной почты и т. Д. Это два отдельных запроса?»

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

На самом деле НЕ распространено видеть ключ «_id» в любом месте, кроме документа верхнего уровня. Кроме того, для коллекций, в которые вы собираетесь иметь миллионы документов, вы сохраняете хранилище, сохраняя ключи «краткими». Вместо «position», а не «position» вместо «projectName», «type» вместо «projectType», «pos», вместо «projectName»), используйте «имя». Это кажется тривиальным, но оно складывается. Вы также захотите поместить индекс в команду «team.empId», так что запрос «сколько проектов работает в Joe Average» работает хорошо.

{ 
    "_id": 444, 
    "name": "My Construction Project", 
    "type": "Construction", 
    "team":[ 
    { "empId": 2345, "pos": "Engineer" }, 
    { "empId": 1234, "pos": "Project Manager" } 
    ] 
} 

Другое дело, чтобы привыкнуть к тому, что вам не придется писать весь документ каждый раз, когда вы хотите обновить отдельное поле или, скажем, добавить новый элемент в команде. Вы можете делать целевые обновления, которые однозначно идентифицируют документ, но только обновляют отдельный элемент поля или массива.

db.projects.update(
    { _id : 444 }, 
    { $addToSet : "team" : { "empId": 666, "position": "Minion" } } 
); 

2 вопроса, чтобы сначала сделать что-то болит, но вы пройдете мимо него.

Answer 2

Mongo DB - это база данных хранения документов. Он поддерживает высокую доступность и масштабируемость.

Чтобы вернуть список всех ваших проектов вместе с командой проекта (подробности), , согласно моему пониманию, вам нужно будет запустить 2 запроса. Поскольку mongoDb не имеет ограничений FK, нам необходимо поддерживать его на уровне программы. Вместо ограничений FK, 1) если данные меньше, то мы можем вставлять данные в качестве вспомогательного документа. 2), а не нормализованный способ проектирования db, в MongoDb нам нужно разработать в соответствии с шаблоном доступа. то есть, как нам нужно запрашивать данные более вероятно. (Однако время для обновления больше (медленное), но в конце пользователя производительность в основном зависит от активности чтения, которая будет лучше, чем для РСУБД).

Следующая ссылка предоставляет курс сертификата на mongo Db бесплатно. Mongo DB University У них также есть форум, который довольно хорош.