Comments on: Entity Relationships in a Document Database

By: Bradley Holt

Bradley Holt — Tue, 14 Aug 2012 14:51:20 +0000

@jonathan: Thanks! Glad you found it helpful. As for the performance of UUIDs, I talked a bit about this in my Scaling CouchDB book. For best performance, you’ll want to use mostly monotonic (basically means sequential) document identifiers. This has to do with the underlying B-tree structure used to store documents. UUIDs are mostly monotonic while still working in a distributed environment, but other approaches could work as well. This is mainly a concern when dealing with large data sets.

By: jonathan

jonathan — Mon, 13 Aug 2012 13:32:05 +0000

Great slides, very helpful, for all of us coming from the SQL world.
Quick question – on the “Additional Techniques” page you mention that UUIDs have better performance than natural keys. Can you elaborate on this? (or at least point me to where I could do some reading on it?)

By: Bradley Holt

Bradley Holt — Sun, 20 May 2012 21:03:13 +0000

@phil westwell: You’re welcome! A fundamental limitation of document databases is that you cannot have atomic transactions across document boundaries. There are very good reasons for this limitation—this limitation brings with it great benefits in the forms of availability and partition tolerance. However, this limitation is a critical one to understand when designing your application and database. So, the short answer is that there is no solution to the problem you mention. If your relationships must be consistent, then they must be in one document. This, of course, precludes use of the Relationship Document pattern.

The slightly longer answer is to use the List of Keys pattern instead (assuming we’re talking about a Many to Many relationship here). This solves the problem for one side of the relationship—the side on which you store the List of Keys—but you still have the problem on the other side of the relationship. Note that when you move from the Relationship Documents pattern to the List of Keys Pattern you are giving up availability (increased probability of document update conflicts) in exchange for consistency. Broadly speaking, document databases are a good fit when availability is more important than consistency. If you must have this level of consistency, then perhaps a document database isn’t a good fit—but note what you’re giving up in terms of availability and partition tolerance.

By: phil westwell

phil westwell — Sun, 20 May 2012 16:13:12 +0000

Thanks for posting this. I think formalising the idea of “view collation” helps think certain problems through.

I thought the “Relationship Document” idea was interesting, but I have some doubts about how it would work in practice that I hope you can clear up.

Say the author document already exists and I want to create a book document. So I (i) use a PUT to add the book and then (ii) use a PUT to add the book-author relationship document.

But if step (ii) fails, then I have a book that has no author. Do you envisage a solution to deal with this?