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

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

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

{
   "id": 1234,
   "firstName": "John",
   "lastName": "Smith",
   "gender": "Male",
   "dateOfBirth": "3/21/1967",
   "emailAddresses":[
      { "email": "[email protected]", "isPrimary": "true" },
      { "email": "[email protected]", "isPrimary": "false" }
   ]
}

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

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

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

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

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

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

Спасибо за вашу помощь.


sql document mongodb azure-cosmosdb mongodb-query
person Sam    schedule 29.08.2014    source источник

Ответы (2)


arrow_upward
7
arrow_downward

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

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

На самом деле НЕ часто можно увидеть ключ «_id» где-либо, кроме документа верхнего уровня. Кроме того, для коллекций, в которых вы собираетесь хранить миллионы документов, вы экономите место, сохраняя ключи «краткими». Рассмотрим «имя», а не «имя проекта», «тип», а не «тип проекта», «поз», а не «позицию». Это кажется тривиальным, но это складывается. Вы также захотите поместить индекс в «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" } }
);

Два запроса, чтобы сделать что-то одно, поначалу причиняют боль, но вы справитесь.

person Bob Kuhar    schedule 29.08.2014
comment
Большое спасибо вам обоим! - person Sam; 29.08.2014

arrow_upward
0
arrow_downward

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

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

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

person Benoy Prakash    schedule 29.08.2014