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 ability to index and query. 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 and 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 indexing and querying. For more information, see Chapter 4, Finding Data with 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 fields for 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 new fields or provide
programming logic that shows a default for older breweries. The
best approach for adding new fields to a document is to perform a
check-and-set operation on the document to change it; with this
type of operation, Couchbase Server will send you a message that
the data has already changed if someone has already changed the
record. For more information about check-and-set methods with
Couchbase, see Section 3.9.3, “Check and Set (CAS)”
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 relates to the id field in the
brewery document. This is analogous to the idea of using a foreign
key in traditional relational database design.
This first document 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 which 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
documents within a document, we create relationships between
application objects.