我正在开发一个API，获取资源的唯一方法是提供像my_resource这样的字符串键。
覆盖_id（这使得一些mongodb驱动程序更容易使用）或它的不好是一个好习惯吗？从长远来看怎么样？
谢谢
答案 0 :(得分：3)
如果使用比ObjectID更自然的主键（例如，字符串值），请随意使用它。
ObjectID的目的是允许分布式客户端根据standard formula快速独立地生成唯一标识符。 12字节的ObjectID公式包括一个4字节的时间戳，3字节的机器标识符，2字节的进程ID和一个以随机值开头的3字节计数器。
如果您生成/分配自己的唯一标识符（即使用字符串），则可能的性能考虑因素是，如果您尝试使用_id插入文档，则不会知道此名称是唯一的。在这种情况下，您需要通过使用新的_id重试插入来处理重复键异常。
答案 1 :(得分：1)
根据我的经验，覆盖_id不是最好的主意。只有当您的数据具有自然唯一且可以轻松用于替换_id的值字段时，才应覆盖_id。但是，覆盖_id只是为了用一个人为的价值来代替它，这没有多大意义。
我建议反对它有几个原因：
首先，这样做需要额外的实现来处理“唯一”值冲突时不可避免的实例。这几乎肯定会出现在任何重要数据库中。这可能是一个问题，因为MongoDB在覆盖值和处理冲突时可能是无情的。换句话说，除非从一开始就非常仔细地设计数据库结构，否则几乎肯定会覆盖值或遇到未处理的异常。
第二，同样重要：ObjectID自然有一个优化的插入公式，可以非常好地创建索引。插入新文档时，创建的ObjectID在数学上尽可能接近前一个ObjectID，从而优化内存和索引功能。可能比自己重新创建这个非常方便的项目更麻烦。
最后，虽然这不是那么重要，但是覆盖_id使得使用standard ObjectID methods变得更加困难。
现在，至少有一个积极的因素我可以考虑覆盖ObjectID：
如果有一个实例肯定永远不会在你的数据库中使用_id，那么它可以为你节省大量的内存，因为MongoDB中的索引成本非常高。