所以我习惯于通过 MySQL 的自动增量主 ID 来查找提交，但是在使用 MongoDB ORM 包装器 Mongoose 之后，我发现由于 Mongo 在集合中存储数据的方式不同，实际上并没有任何传统的概念自增 ID。
我现在一直想弄清楚如何获取提交，因为通常我会像这样构建我的 URL：
submission/34/category/slug-goes-here.
由于34现在使用 Mongo 变成了一个丑陋的基于字符串的 UUID，我不需要在我的 URL 中显示它，但我想要一个唯一的 URL 来查找我的提交。
我正在考虑可能有一个设置方法，当我将提交插入我的数据库时，它会生成某种 6 字符散列，例如zhXk40并像这样查找它。
我想知道如果我这样做，性能权衡会是什么。如果我对 slug 进行限制，然后用 slug 查找它们，并验证类别匹配，那会更有效吗？无论哪种方式，我都必须检查类别和 slug 是否匹配，但我不确定在这种情况下是否真的需要 ID。
创建路线+根据该路线从数据库中查找一些数据的最佳实践是什么？
您应该知道的第一件事是：
该_id属性不一定是那个“丑陋”的ObjectId字符串。
实际上，_id只需要在它的集合中是唯一的，所以如果你想使用自动递增的 ID，没有问题，但是......
如果你打算在你的数据库中使用分片，那么使用自动递增字段_id是矫枉过正的。
为什么？在这里阅读接受的答案：我应该在 MongoDB 中实现自动递增吗？
在我的应用程序中，由于我们不打算对其进行分片，因此我们使用索引的数字 ID 只是为了最终用户更容易使用，并且在内部所有引用都是ObjectIds。
此外，这是在 MongoDB 中创建自动递增字段的好教程：http: //docs.mongodb.org/manual/tutorial/create-an-auto-incrementing-field/
嘘！如果我们能够真正了解这里的最佳实践，我们都会过得更好。会说话的人还在说话，而且会持续一段时间。
我将如何解决这个问题是尽可能漂亮。如果我有一个可用的文本字符串使其具有语义，那将是最好的情况。
如果我不能这样做，我会选择你建议的哈希值。
对于这两种解决方案，挑战将是确保它保持独特性。这意味着在保存之前进行查找。
在性能上，它与 SQL 相同。索引你用来查找的东西。Mongo 在复合索引方面做得很好，所以类别名称和散列会很快查找。