Объекты базы данных (модели), необходимые для базы данных Cosmos

Question

Вопрос1:
Ранее мы использовали WebApi + SqlServer и теперь хотим перейти на WebApi + Cosmos DB.

Более ранняя реализация (WebApi + SqlServer) : 1. Мы создали одну модель Employee, которая будет отображаться на объект из пользовательского интерфейса (почтальон здесь)
2. Позже мы выполним проверки этой модели в WebApi.
3. Далее эта модель будет привязана к объекту DatabaseEmployee (SQL server) и вставлена ​​в сервер SQL.

Новая реализация (WebApi + CosmosDB - SQL API + DocumentDB): 1. Здесь также будут выполнены шаги 1 и 2 выше
2. Нужно ли нам также создавать здесь объект DatabaseEmployee или же мы можем напрямую вставлять данные в CosmosDB без сопоставления модели Employee с моделью DatabaseEmployee?

Примечание: Я думаю:
a) Отображение One-One: не нужно создавать сущность CosmosDB (DatabaseEmployee).
b) Отображение One-Many: мы должны создайте сущность CosmosDB (DatabaseEmployee).
c) Отображение «многие-многие»: мы должны создать сущность CosmosDB (DatabaseEmployee).

Вопрос2:
Для сопоставления One-Many рассмотрите следующий пример 2 таблицы Сотрудник и отдел:
Сотрудник: EmpID, Имя, Адрес
Отдел: DeptID, DeptName , EmpId
На SQL сервере у нас есть ограничения внешнего ключа, поэтому мы можем поддерживать 2 таблицы.
В БД Cosmos нам нужно создать 2 разных контейнера, или достаточно одного контейнера, как показано ниже?

{
DeptId:101,
DeptName: "XXX",
EmpData:
  {
     EmpId: 101,
     Empname:"AAA"
  },
 {
     EmpId: 102,
     Empname:"BBB"
 }
}

Если достаточно одного контейнера, тогда моя модель пользовательского интерфейса должна быть такой:

Public class Department
{
  public int DeptId {get;set;}
  public string Deptname {get;set;}
  public List<Employee> EmpData {get;set;}
}

Но у нас есть такие модели, как:

public class Employee
{
 public int EmpId {get;set;}
 public string EmpName {get;set;}
}

public class Department
{ 
 public int DeptId {get;set;}
 public string DeptName {get;set;}
 public int EMpId {get;set;}  ** ForeignKey constraint as per SQL server **
}

Примечание:
Как поддерживать модель в WebApi и как создавать объекты базы данных, которые напоминают контейнер CosmosDB?

Answer 1

Для отношений «многие ко многим» мы рекомендуем использовать два контейнера и использовать «Изменить канал», чтобы синхронизировать данные между ними c. Однако вы бы сделали это только в том случае, если вы выполняете большие объемы операций чтения и записи как для отделов, так и для сотрудников. Здесь видно, что подразделение организации почти устарело c, и сотрудники часто меняются. Так что все зависит от того, как вы получаете доступ к данным, и вам следует поэкспериментировать, чтобы определить, какая стратегия является наиболее эффективной моделью и ключом раздела.

Контейнер отдела будет иметь идентификатор отдела в качестве ключа раздела с новым документом для каждого сотрудника. Я не стал бы встраивать сотрудников в документ отдела, поскольку он может достигать максимального размера до c размером 2 МБ. Также, если вы часто обновляете отдел с небольшими изменениями в сотрудниках, это будет дорого.

Я бы смоделировал данные в контейнере отдела следующим образом.

{
    deptId:101,
    deptName: "XXX",
    type: "department"
}

{
     empId: 101,
     empName:"AAA",
     deptId: 101,
     type: "employee"
 }

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

Select * FROM c WHERE c.deptId = 101

This вернул бы и отчет отдела и всех его сотрудников. Читая набор результатов в своем коде, вы проверяете свойство «type» и десериализуетесь в правильный тип класса.

На стороне Сотрудника вы делаете противоположное. Ключом вашего раздела будет employeeId, и он будет иметь такую ​​модель.

{
     empId: 101,
     empName:"AAA",
     deptId: 101
}

Обновления идентификатора отдела будут выполняться только для контейнера сотрудников. Используя ленту изменений, вы прослушиваете изменения и затем выполняете вставку в контейнер департаментов, чтобы сохранить их в синхронизации c (именно так вы делаете ссылочную целостность в базе данных No SQL).

Есть много отличных документов о том, как моделировать и разбивать ваши данные в Cosmos DB. Я определенно прочитал бы их, чтобы понять, как лучше проектировать для Космоса.

Данные модели

Данные раздела

Пример из реального мира

Надеюсь, это поможет.