我应该在CouchDB中生成文档的id还是应该依赖CouchDB来生成它？这些方法有哪些优点或缺点？这些选项中是否有任何性能影响？
答案 0 :(得分：6)
就CouchDB而言，没有区别。弗雷德里克是正确的，顺序ID更快。如果查询/_uuids?count=10，您会注意到UUID是顺序的（默认情况下）。
但是，即使使用随机ID，一旦运行压缩，它们将在.couch文件内部处于“正确”顺序，此时没有区别。所以从长远来看，我通常不会担心它。
答案 1 :(得分：1)
主要的是你应该使用大多数顺序ID。正如this article和couchdb book的这一点所解释的那样，使用随机ID会导致内部效率低得多，无论是速度方面还是光盘上使用的空间方面。
答案 2 :(得分：1)
如果您的应用程序有两个或更多单独的实例，则自行生成的ID几乎无法处理。因为不同实例之间的同步不是瞬时的。解决方案可以是让一台服务器专门用于生成（或检查）可用性，例如使用SQL数据库，并充当文档创建的大门。
另一方面，如果你只有一台服务器并且永远不需要更多服务器，那么我发现自我生成的uid有一个优点：因为它们必须是唯一的，你可以在网址中使用它们。例如，将博客文章的标题作为_id。
性能方面，CouchDB生成的id非常长，所以如果你自己的id更短，你将节省大量的磁盘空间（假设你有一些文件）。
答案 3 :(得分：0)
上述两个答案都说明了顺序ID的PROS。 这是序列ID引起的一个主要问题。
使用单个ID的文档中其他ID的可预测性。
由于这个原因，我们不能在应用程序URL中使用顺序ID作为标识符，因为其他ID可以使用一个ID进行预测，并且使用url身份验证也是不可能的。（正如文件共享服务所做的那样）。 / p>