RavenDB дизайн документа, исправления и создание индекса - PullRequest
Новая
       2

RavenDB дизайн документа, исправления и создание индекса

0 голосов
/ 09 марта 2012

Я снова посещаю 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. Dog относится к конкретному Breed, а Breed относится к Group. Dog сторона истории должна быть другим вопросом, но сейчас меня интересует UserEvent сторона.

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

1 Ответ

0 голосов
/ 11 апреля 2012

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

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

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

...