Question

我有以下情况：用户可以在网站上添加联系人（他们是其他用户）。可选地，用户还可以组织他的联系人。用户可以拥有许多电子邮件，地址和电话号码。

我想到了以下架构设计（文档存储/ mongodb）。有什么方法可以改善这个吗？我主要担心的是，个人资料图片嵌入在文档中。我知道这不是一个好习惯，但对于这个特殊目的（赋值），我必须在这里嵌入图片（blob / gridfs）。但我想知道如何改进这种架构。

Answer 1

对于用户，我认为您当前的架构很好。在阵列中保留多个地址，电话号码和电子邮件地址是很好的，因为对于特定的人来说，它们不应该太多，并且很容易查询具有此电子邮件地址的人员＃＆＃34; 34;或者＆＃34;给我这个人的所有电话号码＆＃34;。你似乎确实有一个冗余的e-mail字段 - 是一个特殊的电子邮件，比如帐户的地址，是否与联系电子邮件有所区别？如果是这样，我为其他维护者提供了一个描述性名称，如account_email这样的名称。我不会将照片保留为blob，但你说这是其他一些要求所以我不会批评它。

我喜欢使用单独的联系人集合与群组建立联系的想法。我有一个contacts集合，每个文档代表一个联系人

{
    "_id" : ObjectId("..."),
    "owner_id" : ObjectId("..."), // reference to user document of contact owner
    "contact_id" : ObjectId("..."), // reference to user document of contact
    "group" : "Rivals" // group name
}

{ "owner_id" : 1, "contact_id" : 1 }上的索引，也许是{ "owner_id" : 1, "group" : 1 }，然后快速查询以下内容：

// get all contacts for user x
db.contacts.find({ "owner_id" : x })
// is user y a contact of user x?
db.contacts.count({ "owner_id" : x, "contact_id" : y }) != 0
// get all contacts in group "family" for user x
db.contacts.find({ "owner_id" : x, "group" : "family" })

检索联系人后，为了检索人性化的显示信息，您需要进行第二次查询（应用程序级联接）以检索联系人的实际用户文档。如果需要，可以将一些联系信息非规范化为联系人文档

{
    "_id" : ObjectId("..."),
    "owner_id" : ObjectId("..."), // reference to user document of contact owner
    "contact_id" : ObjectId("..."), // reference to user document of contact
    "group" : "Rivals", // group name
    "contact_name" : "Franke Frankers"
}

如果您包含常用信息，则不需要再进行第二次查询，但如果联系人更新了他/她的信息，您可能需要更新引用它们的每个联系人文档。

更好的方法来建模这个简单的模式设计（MongoDB）？

1 个答案: