When you work with Couchbase Server, using documents to represent data means that database schema is optional; the majority of your effort will be creating one or more documents that will represent application data. This document structure can evolve over time as your application grows and adds new features.
In Couchbase Server you do not need to perform data modeling and establish relationships between tables the way you would in a traditional relational database. Technically every document you store with structure in Couchbase Server has its own implicit schema; the schema is represented in how you organize and nest information in your documents. While you can choose any structure for your documents, the JSON model in particular will help you organize your information in a standard way, and enable you to take advantage of Couchbase Server 2.0. As a developer you benefit in several ways from this approach:
Extend the schema at runtime, or anytime. You can add new fields for a type of item anytime. Changes to your schema can be tracked by a version number, or by other fields as needed.
Document-based data models may better represent the information you want to store and the data structures you need in your application.
You design your application information in documents, rather than model your data for a database.
Converting application information into JSON is very simple, there are many options, and there are many libraries widely available for JSON conversion.
Minimization of one-to-many relationships through use of nested entities therefore, reduction of joins.
When you use JSON documents with Couchbase, you also create an application that can benefit from all the new features of Couchbase 2.0, particularly querying, indexing and views.
There are several considerations to have in mind when you design your JSON document:
Whether you want to use a 'type' field at the highest level of your JSON document in order to group and filter object types.
What particular keys, ids, prefixes or conventions you want to use for items, for instance 'beer_My_Brew.'
When you want a document to expire, if at all, and what expiration would be best.
If want to use a document to access other documents. In other words you can store keys that refer other documents in a JSON document and get the keys through this document. In the NoSQL database jargon, this is often known as 'using composite keys.'
If go to our example of having a beer application which stores information about beers and breweries, this is a sample JSON document to represent a beer. Notice in this case we have a 'type' field with the value 'beer.' This may be useful for grouping together a set of records if we later want to add a 'type' of value 'ale' or 'cider':
{ "beer_id": "beer_Hoptimus_Prime", "type” : “beer”, "abv": 10.0, "category": "North American Ale", "name": "Hoptimus Prime", "style": “Double India Pale Ale” }
Here is another type of document in our application which we use to represent breweries. As in the case of beers, we have a 'type' field we can use now or later to group and categorize our beer producers:
{ "brewery_id": ”brewery_Legacy_Brewing_Co", "type” : “brewery", "name" : "Legacy Brewing Co.", "address": "525 Canal Street Reading, Pennsylvania, 19601 United States", "updated": "2010-07-22 20:00:20" }
What happens if we want to change the fields we store for a brewery? In this case we just add the fields to brewery documents. In this case we decide later that we want to include GPS location of the brewery:
{ "brewery_id": ”brewery_Legacy_Brewing_Co”, "type” : “brewery”, "name" : "Legacy Brewing Co.", "address": "525 Canal Street Reading, Pennsylvania, 19601 United States", "updated": "2010-07-22 20:00:20", "latitude": -75.928469, "longitude": 40.325725 }
So in the case of document-based data, we extend the record by just adding the two new files of 'latitude' and 'longitude.' When we add other breweries after this one, we would include these two new fields. For older breweries we can update them with the field or provide programming logic to show a default for older breweries. The best approach for adding new fields to a document is to perform a CAS operation on the document to change it; Couchbase Server will send you a message that the data has already changed if someone has already changed the record.
To create relationships between items, we again use fields. In this example we create a logical connection between beers and breweries using the 'brewery field' in our beer document which related to the 'id' field in the brewery JSON. This is analogous to the idea of using a foreign key in traditional relational database design.
This first documents represents a beer, Hoptimus Prime:
{ "beer_id": "beer_Hoptimus_Prime", "type” : “beer”, "abv": 10.0, "brewery": ”brewery_Legacy_Brewing_Co", "category": "North American Ale", "name": "Hoptimus Prime", "style": “Double India Pale Ale” }
This second document represents the brewery that brews Hoptimus Prime:
{ "brewery_id": ”brewery_Legacy_Brewing_Co”, "type” : “brewery”, "name" : "Legacy Brewing Co.", "address": "525 Canal Street Reading, Pennsylvania, 19601 United States", "updated": "2010-07-22 20:00:20", "latitude": -75.928469, "longitude": 40.325725 }
In our beer document, the 'brewery' field points to 'brewery_Legacy_Brewery_Co' which is the key for the document that represents the brewery. By using this model of referencing relating documents within a document, we create relationships between application objects.