Как мне смоделировать данные, которые являются наследственными и реляционными, в системе баз данных, ориентированной на документы, такой как RavenDB?

Документно-ориентированные базы данных (особенно RavenDB) действительно интригуют меня, и я хочу немного поиграть с ними. Однако, как человек, очень привыкший к реляционному отображению,Я пытался придумать, как правильно моделировать данные в базе данных документов.

Допустим, у меня есть CRM со следующими объектами в моем приложении C # (без учета ненужных свойств):

public class Company
{
    public int Id { get; set; }
    public IList<Contact> Contacts { get; set; }
    public IList<Task> Tasks { get; set; }
}

public class Contact
{
    public int Id { get; set; }
    public Company Company { get; set; }
    public IList<Task> Tasks { get; set; }
}

public class Task
{
    public int Id { get; set; }
    public Company Company { get; set; }
    public Contact Contact { get; set; }
}

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

Проблема связана с сущностями Задачи . Предположим, бизнес требует, чтобы задача ВСЕГДА была связана с компанией, но, необязательно, также была связана с задачей.

В реляционной модели это легко, поскольку у вас просто есть таблица Задачи и ] Company.Tasks относятся ко всем задачам компании, а Contact.Tasks показывают только задачи для конкретной задачи.

Для моделирования этого в базе данных документов я подумал о следующих трех идеях:

1. Задачи модели как отдельный документ. Это кажется своего рода антидокументной базой данных, поскольку большую часть времени, когда вы смотрите на компанию или на контакт, вы хотите видеть список задач, поэтому вам придется часто выполнять соединения по документам.

2. Сохраняйте задачи, которые не связаны с контакт в списке Company.Tasks и поместите задачи, связанные с контактом, в список для каждого отдельного контакта. К сожалению, это означает, что если вы хотите увидеть все задачи для компании (а их, вероятно, будет много), вам нужно объединить все задачи для компании со всеми задачами для каждого отдельного контакта. Я также вижу, что это сложно, когда вы хотите отделить задачу от контакта, так как вам нужно переместить ее из контакта в компанию

3. Сохраните все задачи в списке Company.Tasks , и каждую contact имеет список значений идентификаторов для задач, с которыми он связан. Это кажется хорошим подходом, за исключением того, что необходимо вручную принимать значения идентификаторов и составлять подсписок сущностей Task для контакта.

Каков рекомендуемый способ моделирования этих данных в документе ориентированная база данных?