我是NoSQL世界的新手，因为我一直在编写RDBMS一段时间。在RDBMS中，每个表都有一个PRIMARY KEY的概念。您使用FOREIGN KEY引用其他表，并且通常，如果非正规化，则您有另一个表，它基本上包含来自表A和表B的映射，因此您可以加入它们。
在Couchbase中，有一个文档ID的概念，其中一个文档在文档本身外部拥有它自己的唯一键。这份文件ID有什么用？我看到它的唯一用途是查询对象本身（使用USE KEYS子句）。
我可以在我的JSON文档中指定“id”和“type”，只为文档密钥分配随机UUID。
使用它可以带来哪些好处？ ELI5如果可能的话。
另外，为什么有些开发人员会在文档ID中添加“prexifes”（例如 客户:: 客户名称。
答案 0 :(得分：4)
这是一个很好的问题，答案既有历史性的，也有技术性的。
历史：Couchbase源自CouchOne / CouchDB和Membase，后者是memcached键值存储的持久分布式版本。 Couchbase仍然作为键值存储运行，检索文档的最快方法是通过键查找。您可以使用基于其中一个文档字段的索引来检索文档，但这样会更慢。
从技术上讲，能够快速检索文档非常的ID是一个优势，使Couchbase对许多用户/应用程序具有吸引力（以及可扩展性和可靠性）。
为什么有些开发者会添加＆＃34;前缀＆＃34;记录ID，例如＆＃34; customer :: {customer name}＆＃34;。有关快速检索和数据建模的问题。我们假设您有一个包含客户基本资料的小文档，并使用客户的电子邮件地址作为文档ID。客户登录，您的应用程序可以使用电子邮件作为ID，使用非常快速的k-v查找来检索此配置文件。您希望将此文档保持在较小的位置，以便更快地检索它。
也许客户有时想查看他们的整个购买历史记录。您的应用程序可能希望将该购买历史记录保存在单独的文档中，因为它太大而无法检索，除非您确实需要它。因此，您将使用文档ID {email} :: purchase_history存储它，以便您可以再次使用k-v查找来检索它。此外，您不需要在任何地方存储购买历史记录的密钥 - 这是隐含的。同样，客户的邮寄地址可能存储在文档ID {email} ::地址下。等
Couchbase中的数据建模与传统的RDBMS一样重要，但你会以不同的方式进行。在免费在线培训中对此进行了很好的讨论：https://training.couchbase.com/online?utm_source=sem&utm_medium=textad&utm_campaign=adwords&utm_term=couchbase%20online%20training&utm_content=&gclid=CMrM66Sgw9MCFYGHfgodSncCGA#
为什么Couchbase仍然使用外部密钥而不是JSON中的主键字段？因为Couchbase仍然允许非JSON数据（例如，二进制数据）。此外，虽然关系数据库可以允许多个字段或字段组合作为候选键，但Couchbase使用文档ID作为其分片版本，因此文档ID不能像其他字段一样对待。