使用Couchbase Server API创建文档时，其中一个参数是文档名称。这用途是什么以及为什么需要它？
使用Couchbase Lite时，您可以创建一个空文档，并为其分配_id和_rev。你不需要给它起个名字。那么Couchbase Server中的这个论点是什么？
答案 0 :(得分：3)
在Couchbase Server中，设计决定所有对象都由对象ID，密钥或名称（不同名称的所有相同内容）标识，并且不会自动分配。这样做的原因是密钥没有嵌入到文档本身中，密钥查找是获取该对象的最快方式，而技术在服务器的引擎盖下决定了这一点。通过ID获取文档比查询文档要快得多。查询意味着您正在提问，而通过ID获取对象意味着您已经知道了答案，并且只是告诉数据库为您获取它并因此更快。
如果ID是随机的，那么您很可能必须查询数据库并且效率较低。 Couchbase Mobile的sync_gateway与Couchbase Lite一起代表您处理此问题，因为它可以拥有自己的密钥空间和密钥查找管理的密钥模式。如果您使用Couchbase SDK直接访问数据库，那么知道密钥将是获取该对象的最快方法。就像我说的，Couchbase Sync_Gateway为您提供了这个查找，因为它是应用服务器。当您直接使用SDK时，您将获得更多控制权并且会出现不同的设计模式。
Couchbase Server中的许多人创建了一个对他们的应用程序有意义的密钥模式。作为用户配置文件存储的示例，我可能会考虑将配置文件拆分为三个单独的文档，每个文档都有一个唯一的用户名（在本例中为hernandez94）：
1）login-data :: hernandez94是具有加密密码的对象，因为出于性能原因，我需要一直查询并希望它在Couchbase的托管缓存中。
2）sec-questions :: hernandez94是具有用户3个安全性问题的对象，因为我不经常使用它，所以不关心它是否在托管缓存中
3）main :: hernandez94是用户的主文档，其中包含我可能需要经常查询的所有其他内容，但不像其他时间那样频繁。
通过这种方式，我已经将我的键空间命名为我的应用程序的访问模式，因此只获得我需要的数据以及我需要的时间以获得最佳性能。如果我想，因为这些关键名称在我的应用程序中是标准化的，我可以对这三个文档进行并列化批量处理，因为我的应用程序可以构造名称，而且非常快。同样，我不是在查询数据，我有钥匙，只是去拿它们。我可以根据应用程序的访问模式进一步规范化这个键空间命名。 email-addresses :: hernandez94，phones :: hernandez94，appl-settings :: hernandez94等。