Question

所以我有用户和产品，每个用户可以拥有多个产品，这将使其成为1对多的关系。现在我正在考虑为包含所有产品文档的每个用户动态创建＆＃34; username＆＃34; _products collation。是否更好地将所有内容存储在1个归类中，这些归类称为具有user_id外键的产品，或者我的设计是否有效且性能提升？

对于Mysql也要考虑同样的事情，最好是拥有1个表用户和第二个带有外键user_id的表产品，还是更好地创建名为＆＃34; username＆＃34; _products？的单独产品表？考虑表现？

我知道索引，如果表格变大，我应该添加索引，如果我使用解决方案编号1只有2个表格/归类而不是多个。

Answer 1

当你在一个集合中拥有尽可能多的时候，MongoDB是最好的。

一个集合行最多可存储16mb。数据是否适合16mb？然后使用一个集合。否则将其拆分为用户集合和user_products集合，其中user_products集合使用用户集合的_id字段（作为一种外键）。

为每个用户制作一个新系列是一件很不容易的事。

Answer 2

mongo（和nosql）违反数据库规范化。您将拥有冗余数据，但这符合nosql提供的精神 - 例如速度和超级易扩展性。

基本上你想在索引键上进行简单而有效的查找。

products = db.products.find("_id": user_id);

您不想通过进行两次查询来模拟联接。

user = db.users.find("_id": user_id);
products_id = user.products_id;
products = db.products.find("_id": products_id);

事实上，即使在RDBMS中做一些完全愚蠢的事情也是可以接受的。又名

products = db.products.find("department": "sales");

产品表上的

// ?! wtf关系信息！？

因为上面需要以下nosql噩梦：

sales_users = db.users.find("department": "sales");
myproductarray = [];
for each record in sales_users {
    products_id = record.products_id;
    products = db.products.find("_id": products_id);
    myproductarray.update(products)
}
return myproductarray;

进一步使用mongo，您可以索引任何键，包括看似愚蠢的键，如“部门”

我强烈认为，您最好推迟表和数据结构，直到至少半完成各种用例和用户界面。例如，如果您的用例决定了这种需求，请在产品表中包含“department”之类的内容。

mongodb数据库设计多个集合或1个大文档？

2 个答案: