A book has an author –an Author has multiple books. A book would be modeled as a document in NoSQL – as would an author. So – we end up with two documents – Book and Author. Each book has a unique title as well as an Author associated with it. This book-author association is part of each Book document.
Case 1 – Changing an Attribute that belongs on multiple documents
Now, supposing the Book title changes –let us say there is a new edition of a textbook. Do you have to update thousands of occurences of the Book document with the new title? The answer is – Yes. However, with a little design change, you can avoid the multiple updates. Instead of having Title as an attribute of the book, suppose you separate Title into its own document (say a document called BookMetaData). Now, each book just has a BookMetaData ID associated with it. If the title of the book changes, one simply needs to update it in the BookMetaData document – and all the associated books will automatically pick up the change.
Couchbase’s alternative to handle multiple document updates
Couchbase offers something of a shortcut – using a view collation. With collated views, you can have a single query spanning all the documents that you might need. With views, Couchbase Server allows one to keep a single canonical source of an item of data while having it show up in many different places.
NoSQL’s mantra – Denormalize, Denormalize !
The relational data model rigidly ties one to database schemas. One resorts to normalization of data and performs joins to perform complex queries. More recently though, changes in application characteristics have led application developers to non-relational database technologies. One can view distributed document database technology as a natural successor to relational database technology:
- It effortlessly scales across virtual machines or cloud instances.
- It doesn’t tie you to a rigid schema before inserting data, nor does it require a schema change when different data must be captured and processed.
- Its rich data model and view technology allows for complex data modeling, capture and queries.
One of the most frequent criticisms of NoSQL is that – updates of any document element suck ! Essentially, an update could require thousands of documents to be simultaneously updated. However, this limitation is easily overcome by allowing a slightly modified design – by separating out the ‘frequently updated’ info into its own document