在文档的流星集合中，我有一个创建者属性。是否建议将用户名（更直观）或userId（user._id）存储为创建者属性？更标准的做法是什么？
答案 0 :(得分：2)
我总是通过id加入馆藏，我建议你也这样做。 id永远不会改变，但底层数据可能会改变。在此示例中，如果用户更改了他/她的用户名，则连接将被破坏。
答案 1 :(得分：1)
使用User._id而不是用户名
的几个原因答案 2 :(得分：1)
对于文档数据库，答案通常是“两者”。
存储userId是必需的，因为它是唯一保证不会更改的字段（正如其他人指出的那样）。
存储“非规范化”数据通常也是值得的。在某些情况下，它实际上是必需的。
以发票上的订单项为例。它需要是静态的，及时的快照。您需要在购买时存储产品信息，即使稍后该产品的名称或其他特性可能会被供应商更改。
在我们的应用中，除了userId之外，我们还有时会存储用户个人资料信息（姓名，联系信息等）。在某些情况下，它严格出于性能原因，在其他情况下，它是审计报告中使用的快照，不得更改。
在性能案例中，如果在“权限来源”中更改了“非规范化”数据，您可能希望有适当的流程来更新“非规范化”数据。在快照案例中，与发票行项目一样，您需要明确不更新它们。有时候，数据已经过时了，不值得保持更新的复杂性。
有关这种“文档与关系”设计讨论的一个很好的例子，请查看这两篇博客帖子：
答案 3 :(得分：0)
使用来自用户集合的_id的最佳理由是，所有流星方法和发布功能都提供this.userId来识别进行呼叫的用户。 userId是您发出客户请求的唯一信息。
如果您在Meteor.users中使用用户名或其他唯一字段，则始终需要按ID查找用户以获取其他字段。