Question

我是古典开发人员，通常从我的Web应用程序开发关系数据库。

我想学习新方法并使用mean.js和mongoDB构建应用程序。我使用了meanjs.org中的yo生成器来开始。

当我对数据建模时，我总是回到经典的关系建模中。而且我认为这不是应用程序构建的“新方式”的全部内容。

所以我的问题是：对我的数据模型样本进行建模的最佳做法是什么？我的学习样本是一个应用程序，其中您有一个特定的音乐专辑列表（如有史以来最好的50张爵士乐专辑），用户可以登记并评价音乐。我有一个CRUD模块，用于添加和编辑用户应该收听的专辑。这以有序的专辑列表结束。

我有一个用户的CRUD模块，由yo生成器生成。用户现在可以看到列表并标记他已经听过的专辑。他应该能够给出评分和评论。

所以问题是：在哪里存储用户listenTo信息？在关系世界中，我将介绍一个新的外键表，它具有从用户到相册的关系，并在外键表中为等级和注释等属性建模。我不认为这是mongo DB世界应该如何工作的，是吗？

我可以将用户listenTo信息添加到每个相册中。我会在每张专辑中都有一个用户和评论列表。然后，我需要确保如果请求列表，则仅存在当前用户的信息。所以我必须在子子文档上过滤属性。感觉很奇怪。或者，我可以为每个新创建的用户复制相册列表，但是当我编辑原始列表时，我需要编写更改用户对象的代码。

你会推荐什么？

Answer 1

当我想到数据建模时，我将其分解为以下关系：

1＆lt; - ＆gt; 1

1＆lt; - ＆gt;很少/很多（有限数量，比如用户电话号码列表）

1＆lt; - ＆gt;很多

MongoDB的一般经验法则是你应该尽可能地嵌入。因此对于1 - ＆lt; - ＆gt; 1和1＆lt; 1＆gt;如果文档大小很小，则很少/很多，您应该将该集合嵌入用户文档中。

在这里考虑用例非常重要。如果我们想要跟踪用户喜欢或收听的所有歌曲，这可能是数百或数千，所以我们可能希望将此信息存储在单独的集合中，并包含对用户的索引引用。

在跟踪用户是否收听歌曲的情况下，我可能会在您的用例中将其结构如下：

{
    _id: ObjectID, // The identifier of the document
    user_id: ObjectID, // The user who listened to the song
    song_id: ObjectID, // The id of the song
    count: number, // The number of times the user listened
    rating: number, // The number of stars the user rated the song
    favorite: boolean, // If the user marked the song as a favorite
    last_listened: Date // The last time the user listened
}

索引为{user_id：1，song_id：1}。

以下是关于如何处理问题的非常好的参考： https://docs.mongodb.com/manual/applications/data-models-relationships/

使用mean.js和mongoose进行数据库建模

1 个答案: