所以，我遇到了一个问题。我有一个服务器正在尝试根据提供的数据生成“漂亮”的 URL。为了讨论，让我们说博客文章的标题。这个 url 显然需要是唯一的，以正确表示资源。好吧，如果我错了，请纠正我。但这在 MongoDB 中不是一个简单的问题吗？
起初我用谷歌搜索了某种类型的自动递增字段。这返回了我的预期，但有一个明显的问题.. 10gen 建议不要这样做。
警告 通常在 MongoDB 中，您不会对 _id 字段或任何字段使用自动增量模式，因为它不适用于具有大量文档的数据库。通常，默认值 ObjectId 更适合 _id。
注意加粗的文本。10gen 不建议您增加任何字段。
所以，回到问题上来。如果我给服务器一个帖子标题，并且我希望它创建一个帖子，我希望它会自动将我的标题更改为一个唯一的标题。例如，如果我创建三个标题为 的帖子foo，我希望服务器为/foo、/foo1、/foo2. 虽然，它可以是任何形式的唯一添加，这里的重点是服务器正在处理创建唯一 url 的肮脏工作，而不是简单地失败并让用户反复尝试提出唯一 url。
话虽如此，这是如何以“MongoDB方式”完成的？10gen 建议不要增加，基本上我能找到的唯一唯一字符串是ObjectID，但/foo50bbe1573b60ff0000000002几乎不是“漂亮”。你不得不承认，如果你被迫使用/foo50bbe1573b60ff0000000002，你还不如直接使用/50bbe1573b60ff0000000002. “漂亮”在前 5 个字符之后早已不复存在。
那么，关于如何以 MongoDB 友好的方式处理这个问题有什么想法/意见吗？
可能的答案： 一个可怕的解决方案是重复文档创建直到唯一的通过，但最多 X 次。例如，
- 你可以试着用标题写
- 如果失败，用标题加上 objectid 的增量值（比如 00002）写入它
- 如果失败了，就用整个该死的objectid来写吧。无论如何，我们已经输了。
可能的答案： 另一个可能的答案，就是按照 10gen 的建议去做，做一个递增的字段。
在上述两种解决方案中，我确信每种方法在不同的方法上都更有效。例如：如果您的唯一字段很可能是唯一的，例如 40 个用户输入的数据字符，则解决方案 1 可能是最好的。如果你处理 4 个字符，它可能会像糖蜜一样慢。
编辑：更好的答案
我认为两者的结合是最好的。拥有一组“原始”网址（例如/foo：），并计算它们被写入的次数。将计数附加到您的目标网址，您就有了一个唯一的网址。我相信这将是 10gen 建议反对的性能问题之间的平衡，同时仍然为您提供增量。