MongoDB：建模喜好、共同朋友等
我正在构建一个流媒体音乐服务，该服务将具有以下功能：
- 关注用户
- 喜欢歌曲
- 创建和管理播放列表
- ...等。
我正在使用 Rails 3.1、Mongoid 和 MongoDB。我不确定应该如何建模我的用户、播放列表和歌曲模型。
播放列表和歌曲之间存在多对多的关系。 Mongoid 将每首歌曲的 ObjectId 存储在每个播放列表的数组中。但我需要为每首歌曲添加一些元数据<->播放列表关系，例如歌曲在特定播放列表中的位置。
我也不确定如何做一些事情，比如找出一个用户与另一个用户有哪些共同的朋友和共同的喜好。在用户文档中存储用户的喜好和朋友真的是个好主意吗？一个用户可能有几千个赞和一千多个朋友等等。
这种东西是否更适合关系数据库？
I'm building a streaming music service that will have features like:
- Follow users
- Like songs
- Create and manage playlists
- ...etc.
I'm using Rails 3.1, Mongoid and MongoDB. I'm unsure how I should model my User, Playlist and Song models.
There is a many to many relationship between playlists and songs. Mongoid is storing ObjectId's of each song in an array of each playlist. But I need to add some metadata to each song <-> playlist relationship, like the position of the song in the specific playlist.
I'm also unsure of how to do things like finding out which mutual friends and mutual likes a user has with another user. Is is really a good idea to store a users likes and friends inside the user document? A user could possibly have several thousand likes and over a thousand friends etc.
Is this kind of stuff better suited for a relational database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我知道这个问题很老了，但值得在这里提供其他人可以阅读的答案。
Mongo 是为诸如“喜欢”之类的概念而构建的。文档存储使添加此类功能变得非常容易，而无需放弃模型、数据或进行任何迁移。
NoSQL 数据库（mongo 不是最快的）速度快如闪电，因此您可以利用这一点并使您的模型变得简单。
我会创建名为“歌曲”、“用户”、“喜欢”和“歌曲”的文档。播放列表，然后在它们之间创建关联。您可以更改逻辑以适合您的情况，但如果您假设播放列表在用户之间共享但由一个用户拥有，您将创建以下关联（根据 mongo 驱动程序，语法将有所不同，下面是 mongomapper）
：将在对象之间创建关联。在您的 User 对象下，您将能够使用 user.playlist 找到该用户关联的播放列表，这将返回关联的播放列表对象的光标。与使用播放列表对象相同，您可以查看所有者或shared_with_users 以这种方式找到您想要的对象。
I know this question is old, but its worth having answers on here that other people can read.
Mongo was built for concepts such as likes. The document store makes is very easy to add features such as this without having to ditch your model, data or do any migration.
NoSQL dbs (and mongo is not the fastest) are lightening quick so you can take advantage of this and make your model simple.
I would create documents called Songs, Users, Likes & Playlists, and then create associations between them. You can change the logic to suit your case, but if you assume that a Playlist is shared between users but owned by one user you would create the following associations (depending on the mongo driver the syntax will be different, below is mongomapper):
This will create associations between the objects. Under your User object you will be able to find the playlists associated by that user using user.playlist which will return a cursor of the playlist objects associated. The same as if you are using the playlist object you can look at the owners or the shared_with_users to find the objects you want that way.
您首先应该问自己的问题是：为什么我要在这个应用程序中使用 mongoDB？
您的需求似乎非常适合关系数据库世界（=对象之间的复杂关系）。所以也许您会更喜欢关系数据库。
您的问题有很多选择（当然每个选项都有权衡）：
客户端连接，
您可以存储一些播放列表中的歌曲
实例）到歌曲中并在客户端加入另一个集合
对于最少使用的播放列表，
关于您的歌曲中的播放列表以及独立的其余部分
收藏。
您的选择是无限的，您必须精确地确定您的需求才能做出好的选择。
如果您只是构建应用程序，请从非常简单的事情开始（也许客户端连接很容易，即使它需要更多请求），然后根据瓶颈开始改进您的模型。
The question you should ask yourself in the first place is : Why do I want to use mongoDB for this application ?
Your need seems well-fitted for relationnal database world (= complex relationship between objects). So maybe you will be happier with a relationnal database.
There are many options to your problem (each of them have trade-offs of course) :
client-side joint
songs
instance) into the songs and client-side join with another collection
for the least used playlist
regarding playlist in your songs and the rest in an independant
collection.
Your options are quite unlimited, you have to precise your needs to be able to make a good choice.
If you are just building you application, start with somehting very simple (maybe client side joint is easy even if it requires more requests) and then start improving your model depending what your bottlenecks are.