Должен ли я денормализировать или запускать несколько запросов в DocumentDb?

Я изучаю моделирование данных в DocumentDb. Вот где мне нужен совет

Пожалуйста, посмотрите, как выглядят мои документы внизу.

Здесь я могу использовать два подхода как с плюсами, так и с минусами.

Сценарий 1:

Если я сохраняю денормализованные данные (см. мои документы ниже), сохраняя информацию о членах проектной группы, т. е. имя, фамилию, адрес электронной почты и т. д., в том же документе, что и проект, я могу получить нужную мне информацию в одном запросе, НО когда Джейн Доу выходит замуж и меняет фамилию, мне придется обновить множество документов в коллекции проектов. Я также должен был бы быть чрезвычайно осторожным, чтобы убедиться, что все коллекции с документами, содержащими информацию о сотрудниках, также обновляются. Если, например, я обновлю имя Джейн Доу в коллекции Projects, но забуду обновить коллекцию TimeSheets, у меня будут проблемы!

Сценарий 2:

Если я немного нормализую данные и оставлю в документах проекта только EmployeeId, я смогу запускать три запроса всякий раз, когда захочу получить список проектов:

• Запрос 1 возвращает список проектов
• Запрос 2 даст мне EmployeeId всех членов команды проекта, которые появляются в первом запросе.
• Запрос 3 для информации о сотруднике, т. е. имени, фамилии, электронной почты и т. д. Я бы использовал результат запроса 2 для запуска этого

Затем я могу объединить все данные в своем приложении.

Проблема здесь в том, что DocumentDb теперь имеет много ограничений. Я могу читать сотни проектов с сотнями сотрудников в проектных командах. Похоже, нет эффективного способа получить всю информацию о сотрудниках, чьи идентификаторы появляются в моем втором запросе. Опять же, пожалуйста, имейте в виду, что мне может понадобиться получить здесь информацию о сотнях сотрудников. Если следующий SQL-запрос — это то, что я бы использовал для данных о сотрудниках, мне, возможно, придется выполнить один и тот же запрос несколько раз, чтобы получить всю необходимую мне информацию, потому что я не думаю, что могу иметь сотни операторов ИЛИ:

SELECT e.Id, e.firstName, e.lastName, e.emailAddress
FROM Employees e
WHERE e.Id = 1111 OR e.Id = 2222

Я понимаю, что DocumentDb все еще находится в предварительной версии, и некоторые из этих ограничений будут исправлены. С учетом сказанного, как мне подойти к этой проблеме? Как я могу эффективно хранить/управлять и извлекать все необходимые данные проекта, включая информацию о команде проекта? Является ли Сценарий 1 лучшим решением или Сценарий 2, или есть лучший третий вариант?

Вот как выглядят мои документы. Во-первых, проектный документ:

{
   id: 789,
   projectName: "My first project",
   startDate: "9/6/2014",
   projectTeam: [
      { id: 1111, firstName: "John", lastName: "Smith", position: "Sr. Engineer" },
      { id: 2222, firstName: "Jane", lastName: "Doe", position: "Project Manager" }
   ]
}

А вот два документа сотрудников, которые находятся в коллекции Employees:

{
   id: 1111,
   firstName: "John",
   lastName: "Smith",
   dateOfBirth: "1/1/1967',
   emailAddresses: [
      { email: "[email protected]", isPrimary: "true" },
      { email: "[email protected]", isPrimary: "false" }
   ]
},
{
   id: 2222,
   firstName: "Jane",
   lastName: "Doe",
   dateOfBirth: "3/8/1975',
   emailAddresses: [
      { email: "[email protected]", isPrimary: "true" }
   ]
}