我在 MongoDB 数据库中存储了两个集合：
==网站==
id
nickname
url
==检查==
id
website_id
status
我想显示带有相应网站昵称的检查状态列表。
例如：
[Google, 200]
我有数千张支票，但只有几个网站。
哪个更有效率？
将网站昵称直接存储在“check”中。这意味着如果昵称被更改，我将不得不对数千个文档进行大规模更新。
返回一个多维数组，其中站点 ID 是键，昵称是值。这将在遍历检查列表时使用。
我已经读到 #1 并不算太糟糕（在 NoSQL 世界中），事实上，它可能是首选？是吗？
【问题讨论】：
如果只是几个网站，我会选择选项 1 - 不像在关系/SQL 世界中那样干净和规范化，但它比尝试使用 MongoDB 模拟连接更有效且痛苦得多。使用 MongoDB 或任何其他 NoSQL 数据库要记住的是，您通常会做出某种权衡——没有什么是免费的。我个人非常重视面向无模式文档的数据设计，对于我使用它的应用程序，我很容易做出权衡（比如没有连接和事务）。
也就是说，这是一种权衡——所以在这种情况下总是要问自己的一件事是，我为什么要使用 MongoDB 或其他一些 NoSQL 数据库？是的，它很时髦且“热门”，但我会确保您所做的事情对于 NoSQL 方法是有意义的。如果您花费大量时间解决缺少连接和外键、没有事务以及您在 SQL 世界中习惯的其他事情，我会认真考虑这是否最适合您的问题。
【讨论】：
您可能会考虑第三种选择：删除 Checks 集合并将每个网站的检查作为数组嵌入每个 Websites 文档中。
这样可以避免任何 JOIN 并避免不一致，因为没有 Website 所属的 Check 就不可能存在。
但是，仅当每个文档的 checks 数组随时间保持相对恒定且不会不断增长时，才建议这样做。在 MongoDB 中应该避免快速增长的文档，因为每当一个文档的大小翻倍时，它就会被移动到存储它的物理文件中的不同位置，这会减慢写操作的速度。此外，MongoDB 对每个文档有 16MB 的限制。存在此限制主要是为了阻止不断增长的文档。
您还没有说Check 在您的应用程序中实际上是什么。当它是您定期执行的任务列表并且只是偶尔更改时，嵌入不会有任何问题。但是当你收集你曾经做过的所有检查的历史结果时，我宁愿建议将每个结果（集合？）放在一个自己的文档中，以避免文档增长。
【讨论】：
Checks 和Websites，那么让nickname 不受检查是有意义的——为什么check 应该关心website 的nickname？听起来我应该避免试图伪造一个 JOIN 并且不断地附加到一个文档中。也许我会不显示nickname 而只显示URL。想法？