10.1. Document Design Considerations¶
When designing your database, and your document structure, there are a number of best practices to take into consideration. Especially for people accustomed to relational databases, some of these techniques may be non-obvious.
10.1.1. Don’t rely on CouchDB’s auto-UUID generation¶
While CouchDB will generate a unique identifier for the
_id field of any doc
that you create, in most cases you are better off generating them yourself for
a few reasons:
- If for any reason you miss the
200 OKreply from CouchDB, and storing the document is attempted again, you would end up with the same document content stored under duplicate
_ids. This could easily happen with intermediary proxies and cache systems that may not inform developers that the failed transaction is being retried.
_ids are are the only unique enforced value within CouchDB so you might as well make use of this. CouchDB stores its documents in a B+ tree. Each additional or updated document is stored as a leaf node, and may require re-writing intermediary and parent nodes. You may be able to take advantage of sequencing your own ids more effectively than the automatically generated ids if you can arrange them to be sequential yourself.
10.1.2. Alternatives to auto-incrementing sequences¶
Because of replication, as well as the distributed nature of CouchDB, it is not practical to use auto-incrementing sequences with CouchDB. These are often used to ensure unique identifiers for each row in a database table. CouchDB generates unique ids on its own and you can specify your own as well, so you don’t really need a sequence here. If you use a sequence for something else, you will be better off finding another way to express it in CouchDB in another way.