Why does the Couchbase Server API require a name for new documents

In Couchbase Server, the design decision is that all objects are identified by an object ID, key, or name (all the same with different names), and they are not automatically assigned. The reason for this is that the keys are not embedded in the document itself, key searches are the fastest way to get this object, and technology dictates this under the hood of the server. Retrieving a document by ID is much faster than requesting it. A query means you are asking a question, whereas getting an object by id means you already know the answer and just tell the DB to get it for you and therefore it's faster.

If the identifier is random, then most likely you have to query the database and this is less efficient. Couchbase Mobile sync_gateway together with Couchbase Lite handles this on your behalf if you want it to be able to have its own keyspace and key pattern that it manages for key searches. If you directly navigate to the DB using the Couchbase SDK, knowing that this key will be the fastest way to get this object. As I said, Couchbase Sync_Gateway passes this lookup for you since it is an application server. When you go directly from the SDK, you gain more control and various design patterns appear.

Many people on Couchbase Server create a key pattern that means something to their application. As an example for a user profile store, I could consider splitting a profile into three separate documents with a unique username (in this example hernandez94) for each document:

1) login-data :: hernandez94 is an object that has an encrypted password as I need to ask for it all the time and use it in the Couchbase control cache for performance reasons.

2) sec-questions :: hernandez94 is an object that has 3 user security questions and since I don't use it very often I don't care if it's in managed cache

3) main :: hernandez94 is the main user document, which contains everything else that I might need often, but not as often as at other times.

This way I have adapted my keyspace to named application access models and therefore only get the data I need and exactly when I need it for best performance. If I want, since these key names are standardized in my application, I could do a parallelized array on all three of these documents, since my application can build the name and it will be VERY fast. Again, I am not asking for data, I have the keys, just understand them. I could normalize the naming of this key space depending on my application's access patterns. email addresses :: hernandez94, phone numbers :: hernandez94, appl-settings :: hernandez94, etc.