Couchbase: How Do I Benefit From Using Document ID?
I am new to the NoSQL world as I have been programming RDBMS for a while. In an RDBMS, you have the concept of a PRIMARY KEY for each table. You are referencing other tables using FOREIGN KEYs, and usually if you denormalize them well, you have another table that basically contains a mapping from tables A and TABLE B for you to join.
Couchbase has this concept of document identifier, where the document has its own unique key, external from the document itself. What is the document ID for? The only thing I can see for it is a request for the object itself (using the USE KEYS clause).
I could just specify "id" and "type" in my JSON document and just assign random UUIDs to the document key.
What benefits do I get from using it? ELI5 if possible.
And also why some developers add "prexifes" to the document id (for example, client: username>.
source to share
This is a great question and the answer is both historical and technical.
Historical: Couchbase derives from CouchOne / CouchDB and Membase, the latter of which is a persistent distributed version of the memcached key store. Couchbase still acts as a key store, and the fastest way to get a document is through a key search. You can get the document using an index based on one of the document's fields, but this will be slower.
Technically, the ability to quickly retrieve documents based on their ID is one of the advantages that makes Couchbase attractive to many users / applications (along with scalability and reliability).
Why do some developers add "prefixes" to document identifiers such as "customer :: {customer name]". For questions related to quick search and data modeling. Let's say you have a small document containing a customer baseline profile and you use the customer's email address as the document ID. A client logs in and your app can get this profile using a very fast kv search using email as an id. You want this document to be small so that you can find it faster.
Perhaps the customer sometimes wants to view the entire purchase history. Your application might want to keep this purchase history in a separate document because it is too large to retrieve if you really don't need it. So you save it with the document id {email} :: purchase_history so you can use the kv search again to get it. Plus, you don't need to store the key to record your purchase history anywhere - this is implied. Similarly, customer addresses can be stored in the ID {email} :: address document. Etc.
Data modeling in Couchbase is just as important as it is in a traditional RDBMS, but you go differently. There's a good discussion of this in a free online tutorial: https://training.couchbase.com/online?utm_source=sem&utm_medium=textad&utm_campaign=adwords&utm_term=couchbase%20online%20training&utm_content=&gclid=CMrM66YGHw9MCFGod
Why is Couchbase still using a foreign key instead of a primary key field inside JSON? As Couchbase still allows non-JSON data (like binary data). Also, while a relational database can allow multiple fields or combinations of fields to be candidate keys, Couchbase uses the document ID for its sharding version, so the document ID cannot be treated like other fields.
source to share