Couchbase is schema-less. That runs against the grain of traditional, RDBMS history and experience, but it's proven to be one of the most lauded features of NoSQL databases.<\/p>\n
Not being required to develop a schema before you build your application is a huge time saver. It enables quick prototyping and lets you mold the structure of your document as you delve into its different uses within your application.<\/p>\n
However, the lack of a required, formal schema, does not mean your documents don't gain value from having a consistent structure or “inherent” schema.<\/p>\n
One of the key considerations when crafting your documents for Couchbase is how granularly to split your data: one document or multiple documents for a single concept?<\/p>\n
Here are the key decision makers when choosing how to construct your data in Couchbase:<\/p>\n
What does this document look like in real life?<\/em> How often will I update this?<\/em><\/p>\n Breweries and Beers are fairly static topics. It's more likely that we'll be adding Beer documents to a Brewery's portfolio rather than updating a Beer's description or changing a Brewery's address. Those things happen, but it's rare when compared with stock tickers, sensor data, or social game actions.<\/p>\n Do you want all this data updated together?<\/em> Currently it looks like we have two available options when designing documents:<\/p>\n However, there's a third option: determine the canonical data later with MapReduce. Content can be structured in such a way that it will exist more like a “general ledger” from which you can build an index that states what the canonical data is from among the documents. Plus, you can leave the past (now “stale”) data in the database without having to worry about the effects of that stale data on how you view the active material. This can prove advantageous if you'd prefer to have that historical data available. In this case, we could put the address of the brewery on both the Brewery and Beer documents and be able to find that a Beer was originally crafted at the Brewery's original location. Interesting options abound!<\/p>\n Since Couchbase is de-normalization friendly, we could put the Brewery data in each Beer document:<\/p>\n This could save us a great deal of request time. It could also serve as a history record of where the beer was original brewed (if the address of the brewery changed years later). If we need the canonical brewery info in our app (vs. possibly stale data), then we can construct the brewery ID from it's name (at least in this app), and look up the address from the authoritative Brewery document. The Brewery document would be the canonical source of information about the Brewery, and the Brewery address information on the Beer document could serve as a historical reference.<\/p>\n Let's flip that last example on it's head. Brewery's brew beers. If they've not given away the recipe (or even if they have), you can't get that particular beer, made that particular way, with that special mountain water (or whatever) from anyone but that brewery. So why not store all the beers within a Brewery document?<\/p>\n Let's take a look at what this new structure might look like. The first several lines are from the original New Belgium Brewing document. The new addition is the “beers” key and the object of beer information set as its value.<\/p>\n Our new “beers” child-object has keys for each beer using nearly the same IDs as keys for Beer documents we saw earlier (just without the “beer_” prefix).<\/p>\n Either of these approaches could be valid for different use cases. In cases where you want quick retrieval of a relationship “package” going the single, combined document route can be a great optimization.<\/p>\n Enjoy the freedom, consider your options, and get that prototype built!<\/p>\n Next up, we'll look at how to build indexes from the original Beer and Brewery documents. Stay tuned!<\/p>\n","protected":false},"excerpt":{"rendered":" Couchbase is schema-less. That runs against the grain of traditional, RDBMS history and experience, but it's proven to be one of the most lauded features of NoSQL databases. Not being required to develop a schema before you build your application […]<\/p>\n","protected":false},"author":36,"featured_media":13873,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"ppma_author":[9010],"class_list":["post-1754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"acf":[],"yoast_head":"\n
\nIn our case, we have Breweries and their Beer. We have a noun for each, and in the earlier post, we had a document for each. It feels natural, and makes sense.<\/p>\n
\nIn Couchbase, the document is the smallest level of atomicity. If we combine Brewery and Beer data into a single document, all changes to Beer data require sending the entire Brewery document that contains it as well. All creation and update operations happen on that entire collection as if it were a single thing. This has the advantage of consolidating disparate updates into single, streamlined requests, but has the disadvantage of requiring a larger update each time a change is made to any of the contained concepts.<\/p>\n\n
Beer with Brewery Object<\/h3>\n
\n\u00a0 \u00a0“_id”<\/span>:<\/span> “beer_1554_Enlightened_Black_Ale”<\/span>,<\/span>
\n\u00a0 \u00a0“_rev”<\/span>:<\/span> “1-191ae52a6c773fd7749b65ffd9ae8044”<\/span>,<\/span>
\n\u00a0 \u00a0“brewery”<\/span>:<\/span> {<\/span>
\n\u00a0 \u00a0 \u00a0 “name”<\/span>:<\/span> “New Belgium Brewing”<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 “address”<\/span>:<\/span> [<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0“500 Linden Street”<\/span>
\n\u00a0 \u00a0 \u00a0 ]<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 “city”<\/span>:<\/span> “Fort Collins”<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 “state”<\/span>:<\/span> “Colorado”<\/span>
\n\u00a0 \u00a0 \u00a0…
\n\u00a0 \u00a0}<\/span>
\n\u00a0 \u00a0“name”<\/span>:<\/span> “1554 Enlightened Black Ale”<\/span>,<\/span>
\n\u00a0 \u00a0“abv”<\/span>:<\/span> “5.5”<\/span>,<\/span>
\n\u00a0 \u00a0…
\n\u00a0 \u00a0“category”<\/span>:<\/span> “Belgian and French Ale”<\/span>,<\/span>
\n\u00a0 \u00a0“style”<\/span>:<\/span> “Other Belgian-Style Ales”<\/span>,<\/span>
\n\u00a0 \u00a0“updated”<\/span>:<\/span> “2010-07-22 20:00:20”<\/span>
\n}<\/span><\/div>\n<\/div>\nPros:<\/h4>\n
\n
Cons:<\/h4>\n
\n
Brewery with Beer Objects<\/h3>\n
\n\u00a0 \u00a0“_id”<\/span>:<\/span> “brewery_New_Belgium_Brewing”<\/span>,<\/span>
\n\u00a0 \u00a0“_rev”<\/span>:<\/span> “1-e405d6f86ec028a4fe0d18be0a6d4fa1”<\/span>,<\/span>
\n\u00a0 \u00a0“name”<\/span>:<\/span> “New Belgium Brewing”<\/span>,<\/span>
\n\u00a0 \u00a0“address”<\/span>:<\/span> [<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0“500 Linden Street”<\/span>
\n\u00a0 \u00a0]<\/span>,<\/span>
\n\u00a0 \u00a0…..
\n\u00a0 \u00a0“geo”<\/span>:<\/span> {<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0“loc”<\/span>:<\/span> [<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0“-105.07”<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0“40.5929”<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0]<\/span>
\n\u00a0 \u00a0}<\/span>,<\/span>
\n\u00a0 \u00a0“updated”<\/span>:<\/span> “2010-07-22 20:00:20”<\/span>,<\/span>
\n\u00a0 \u00a0“beers”<\/span>:<\/span> {<\/span>
\n\u00a0 \u00a0 \u00a0 “1554_Enlightened_Black_Ale”<\/span>:<\/span> {<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 “name”<\/span>:<\/span> “1554 Enlightened Black Ale”<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 “abv”<\/span>:<\/span> “5.5”<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 “category”<\/span>:<\/span> “Belgian and French Ale”<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 \u00a0 “style”<\/span>:<\/span> “Other Belgian-Style Ales”<\/span>
\n\u00a0 \u00a0 \u00a0 }<\/span>,<\/span>
\n\u00a0 \u00a0 \u00a0 “beer_Fat_Tire”<\/span>:<\/span> {<\/span>…}<\/span>
\n\u00a0 \u00a0}<\/span>
\n}<\/span><\/div>\n<\/div>\nPros:<\/h4>\n
\n
Cons:<\/h4>\n
\n
Conclusion<\/h3>\n