MongoDB 设计 - 使用唯一索引与使用 _id 强制字段唯一性的好处答案

【问题标题】：MongoDB Design - Benefits of Using Unique Indexes vs. Using _id to Enforce Uniqueness of FieldMongoDB 设计 - 使用唯一索引与使用 _id 强制字段唯一性的好处
【发布时间】：2020-02-21 22:00:26
【问题描述】：

我对在 MongoDB 中强制字段唯一性时的当前最佳实践有疑问。

例如，假设我正在使用注册用户，并且我想强制每个用户都需要有一个唯一的电子邮件地址。我有 3 个选项（#3 与其他选项不互斥）：

将_id 字段覆盖为电子邮件地址
在 emailAddress 字段上创建唯一索引，保持 _id 字段不变（且未使用）
确保 API 在 emailAddress 字段中插入数据库之前检查重复项

我认为#3 是必不可少的，不管#1 和#2，但我还应该怎么做呢？

我是否也应该将 _id 字段覆盖为电子邮件地址 (#1)，因为我不需要 2 个唯一字段，还是应该在 emailAddress 上创建唯一索引并将 _id 字段保留为是（＃2）？也许两者都不是？

每个选项的优点/缺点是什么？

【问题讨论】：

标签： mongodb

【解决方案1】：

将_id 字段覆盖为电子邮件地址

如果电子邮件地址是唯一的并且永远不会更改，则将电子邮件用作 _id 可以为您节省一个额外的字段和索引（因此会节省一些存储空间和开销）。但是，由于_id 是不可变的，因此更改电子邮件地址需要更多工作：复制并插入带有新_id 的当前文档，然后删除带有原始电子邮件地址的文档。

在 emailAddress 字段上创建唯一索引，保持 _id 字段不变（且未使用）

如果您需要强制使用唯一的电子邮件地址但可能允许您的用户将来更改它，这是最好的选择。在这种情况下，_id 字段没有被使用：它仍然是唯一标识文档的主键。

确保 API 在 emailAddress 字段中插入数据库之前检查重复项

这在前两种情况下都不需要。具有唯一索引的插入/更新将引发您的 API 必须处理的重复键异常。

如果您没有具有强制执行唯一电子邮件地址的索引，则此检查也不可靠：对于并发客户端，可能会在客户端检查存在与插入/更新操作发生。

【讨论】：

【解决方案2】：

不理会_ID。 #3 是一个应用程序决定，您的应用程序是否只有唯一的电子邮件至关重要 - 它与索引无关 - 以及您如何拒绝重复的电子邮件尝试，无论有效还是错误仅与您的应用程序的个性有关。

您的索引应该根据您的查询需求来设置。它们不必是唯一的。即 State 上的索引...考虑查询将如何发生并相应地计划您的数据模式和索引...在 NoSQL 中，索引非常关键...

为了唯一性考虑 2 个字段的组合键...

【讨论】：