Дизайн, создание патчей и создание индекса RavenDB

Question

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

public class UserEvent 
{ 
    public UserEvent() 
    { 
     Shows = new List<Show>(); 
    } 
    public readonly string IdPrefix = "Events/"; 
    public string Id { get; set; } 
    public string Title { get; set; } 
    public List<Show> Shows { get; set; } 
} 

public class Show 
{ 
    public Show() 
    { 
     Entries = new List<ShowEntry>(); 
    } 
    public readonly string IdPrefix = "Shows/"; 
    public string Id { get; set; } 
    public string EventId { get; set; } 
    public string Name { get; set; } 
    public DateTime Date { get; set; } 
    public List<ShowEntry> Entries { get; set; } 
} 

public class ShowEntry 
{ 
    public readonly string IdPrefix = "ShowEntries/"; 
    public string Id { get; set; } 
    public string DogId { get; set; } 
    public string OwnerName { get; set; } 
    public EntryClass Class { get; set; } 
} 

Прежде всего, это разумный дизайн? A UserEvent обычно имеет несколько (менее 6) Show, но Show может иметь от десятков до сотен ShowEntry. Я включил DogId в ShowEntry, но, возможно, позже я изменю его до свойства Dog типа. A Dog относится к конкретному Breed, а a Breed относится к Group. Сторона истории должна быть другим вопросом, но на данный момент меня интересует сторона UserEvent.

Если мои документы разработаны таким образом, я могу использовать API-интерфейс Patching API для добавления элементов в коллекцию Entries в пределах Show? Я хотел бы иметь индекс, который будет суммировать записи, основанные на свойствах Собаки. Будут ли индексы обрабатываться, если документ исправлен?

Answer 1

Ваш дизайн, безусловно, выглядит разумным с внешней точки зрения. Большой вопрос, который вам нужно задать самому себе: «Что вы планируете чаще всего запрашивать?»

Например, Show, похоже, является довольно распространенным объектом, который может быть полезен для использования в качестве составного корня (из проекта, управляемого доменом). Я нахожу, что при организации моих документов самый важный вопрос: «Как часто вы планируете запрашивать объект».

Чтобы ответить на ваш последний вопрос, исправление должно обязательно вызвать повторную индексацию.