Таким же образом, мое мнение таково: если Задачи принадлежат компании, они остаются внутри Компании. Компания - Совокупный Корень Задач. Контакты могут содержать только ссылки (идентификаторы) или копии Задач и не могут изменять их напрямую. Если у вашего контакта есть «копия» задания, это нормально, но для того, чтобы изменить задание (например, пометить его как завершенное), вы должны изменить задание через его Совокупный корень (компания). Поскольку копия может быстро устареть, создается впечатление, что вы хотите, чтобы копия существовала только в памяти и при сохранении контакта, вы сохраняете только ссылки на задачи.
ентно-ориентированные базы данных (особенно 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 документ, так как контакты и задачи не имеют цели вне компании, и большую часть времени запрос для задачи или контактов также будет отображать информацию о связанной компании.
Проблема идет сTask юридические лица. Скажем, бизнес требует, чтобы задача ВСЕГДА была связана с компанией, но при желании также связана с задачей.
В реляционной модели это легко, так как у вас просто естьTasks стол и естьCompany.Tasks относятся ко всем задачам для компании, аContact.Tasks показывать только задачи для конкретной задачи.
Для моделирования этого в базе данных документов я подумал о следующих трех идеях:
Задачи модели в виде отдельного документа. Это кажется своего рода антидокументарной базой данных, так как большую часть времени, когда вы смотрите на компанию или контакт, вы захотите увидеть список задач, поэтому вам придется много выполнять объединения документов.
Сохраняйте задачи, не связанные с контактом, вCompany.Tasks перечислите и поместите задачи, связанные с контактом, в список для каждого отдельного контакта. К сожалению, это означает, что если вы хотите увидеть все задачи для компании (которых, вероятно, будет много), вам нужно объединить все задачи для компании со всеми задачами для каждого отдельного контакта. Я также вижу, что это сложно, когда вы хотите отделить задачу от контакта, так как вам нужно перенести ее из контакта в компанию.
Храните все задачи вCompany.Tasks список, и у каждого контакта есть список значений идентификаторов для задач, с которыми он связан. Это кажется хорошим подходом, за исключением необходимости принимать значения идентификаторов вручную и составлять подсписокTask лица для контакта.
Каков рекомендуемый способ моделирования этих данных в ориентированной на документы базе данных?