2014-09-11 6 views
4

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

Пока что большинство примеров управления данными с помощью DocumentDb используют простые объекты, но в реальной жизни мы почти никогда не делаем. Я просто хочу понять, как и где мне нужно обрабатывать сложные классы, прежде чем я сохраню их как объекты Json в DocumentDb.

Давайте рассмотрим следующий пример. Я буду сохранять информацию о проекте в коллекции проектов, но я НЕ хочу сохранять полные имена людей в команде проекта в рамках проектного документа. Я просто хочу сохранить их EmployeeId в проектном документе. У меня есть отдельная коллекция сотрудников, где я хочу сохранить информацию о человеке/сотруднике. Мой объект проекта выглядит следующим образом:

public class Project 
{ 
    [JsonProperty(PropertyName="id")] 
    public int ProjectId {get; set;} 

    [JsonProperty(PropertyName="projectName")] 
    public string ProjectName {get; set;} 

    [JsonProperty(PropertyName="projectType")] 
    public string ProjectType {get; set;} 

    [JsonProperty(PropertyName="projectTeam")] 
    public List<TeamMember> ProjectTeam {get; set} 
} 

Мой класс командного игрока наследует от объекта Employee и выглядит следующим образом:

public class TeamMember : Employee 
{ 
    [JsonProperty(PropertyName="position")] 
    public string Position {get; set;} 
} 

Мой класс Employee выглядит следующим образом:

public class Employee 
{ 
    [JsonProperty(PropertyName="id")] 
    public int EmployeeId {get; set;} 

    [JsonProperty(PropertyName="firstName")] 
    public string FirstName {get; set;} 

    [JsonProperty(PropertyName="lastName")] 
    public string LastName {get; set;} 

    [JsonProperty(PropertyName="gender")] 
    public string Gender {get; set;} 

    [JsonProperty(PropertyName="emailAddress")] 
    public string EmailAddress {get; set;} 
} 

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

{ 
    id: 12345, 
    projectName: "My first project", 
    projectType: "Construction Project", 
    projectTeam: [ 
     { id: 7777, position: "Engineer" }, 
     { id: 8998, position: "Project Manager" } 
    ] 
} 

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

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

Я могу думать о двух местах, чтобы справиться с этим, но я хочу, чтобы понять, есть ли лучше, более прямой способ сделать это:

  1. я могу преобразовать мой класс проекта в объект JSON в моих C# код и передать объект JSON в DocumentDb для хранения.
  2. В качестве альтернативы я могу передать объект Project непосредственно в DocumentDb в хранимую процедуру JavaScript, и я могу обрабатывать развязывание и хранение данных в двух или более коллекциях в DocumentDb.

Вот что я хотел бы знать:

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

Я ценю вашу помощь. Спасибо.

ответ

7

в магазине NoSql, таком как этот, вы можете хранить различные типы документов с различными схемами в одной коллекции.

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

теперь все это говорит; если вы все еще хотели это сделать, то вы можете ... , чтобы достичь этого, ваш объект проекта должен будет измениться. вместо того, командный игрок: Сотрудник (который будет включать в себя весь объект Employee) есть объект командного игрока имитировать то, что вы хотите от вашего JSON ... т.е.

class TeamMember 
{ 
    int id {get;set;} 
    string position {get;set;} 
} 

Теперь, когда DocumentDB упорядочивает свой объект проекта, который бы в конечном итоге с JSON, который походил на то, что вы хотели. И тогда вы можете отдельно сохранить объект Employee в другом месте.

Если вы не хотите этого делать или не можете сделать это, потому что вы не контролируете определение Модели или потому, что другие части системы построены так, чтобы зависеть от этого, тогда вы можете исследовать здание пользовательский конвертер JSON для вашего объекта Project, который выплюнул бы JSON, который вы хотели. Затем украсьте свой объект Project этим JsonConverter, и когда DocumentDB выполнит преобразование, каждый раз будет создан правильный результат.

+2

Райан, вы правы! Я рассматривал коллекции как таблицы. Как я могу указать, какой тип документа я хочу запросить, если я храню оба проекта и сотрудников в одной коллекции? – Sam

+1

Самый простой способ сделать это сегодня - добавить атрибут «type» для каждого документа JSON и включить его в запрос. WHERE type = project или WHERE type = employee Я знаю, что вы ограничены только тремя статьями в ГДЕ сегодня, но это, вероятно, будет изменено в любой день, чтобы позволить больше. Мы хотели бы услышать, если бы были другие способы, которые облегчили бы вам работу, поэтому, пожалуйста, держите обратную связь. –

+0

Еще раз спасибо Ryan – Sam

Смежные вопросы