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