所以我有用户和产品，每个用户可以有多个产品，这将使其成为一对多的关系。现在我正在考虑为每个包含所有产品文档的用户动态创建“用户名”_products 排序规则。 将所有内容存储在 1 个称为 products 的排序规则中是否更好，该排序规则具有 user_id 的外键，还是我的设计有效且性能得到改善？
同样考虑 Mysql 的情况，最好有 1 个表用户和第二个具有外键 user_id 的表产品，还是创建名为“用户名”_products 的单独产品表更好？考虑性能？
我知道索引，如果表变大并且如果我使用解决方案 1 只有 2 个表/排序规则而不是多个，我应该在任何情况下添加索引。
【问题讨论】：
标签： mongodb database-design database
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 中做一些完全愚蠢的事情，在 nosql 中也是可以接受的。又名
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，您可以索引任何键，包括看似愚蠢的键，例如“部门”
在我看来，您最好将表格和数据结构推迟到至少完成各种用例和用户界面的半成品。例如，如果您的用例需要，请在产品表中包含“部门”之类的内容。
【讨论】：
当你在一个集合中拥有尽可能多的东西时，MongoDB 是最好的。
一个集合行最多可以存储 16mb。数据适合那个 16mb 吗？然后使用一个集合。否则将其拆分为用户集合和 user_products 集合，其中 user_products 集合使用用户集合的 _id 字段（作为一种外键）。
为每个用户制作一个新系列是一件大事。
【讨论】：