面向文档的数据库(尤其是 RavenDB)真的很吸引我,我想尝试一下它们。然而,作为一个非常习惯关系映射的人,我试图思考如何在文档数据库中正确地建模数据。
假设我的 C# 应用程序中有一个包含以下实体的 CRM(省略了不需要的属性):
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
列表中,每个联系人都有一个与其关联的任务的 id 值列表。Task
除了必须手动获取 id 值和必须为联系人制作实体子列表之外,这似乎是一个不错的方法。
在面向文档的数据库中对这些数据建模的推荐方法是什么?