Category Archives: Couchbase

This blog is to give you a basic idea of data modeling in Couchbase Server and it compares with the Relational model to understand the power of Document oriented database i.e., Couchbase Server:

Couchbase documents are JSON, a self-describing format capable of representing rich structures and relationships. Unlike a traditional RDBMS, the schema in Couchbase Server is a logical construct entirely defined in the application code and captured in the structure of the stored documents. Since there is no explicit schema to maintain, developers can add new objects and properties at any time just by pushing new application code that stores new JSON, without having to also make the same changes to the schemas. This allows applications to evolve quickly and seamlessly.

Let’s understand this flexibility and dynamic schema with an example:

Say for example we have a requirement to store a Product information in some online shopping application or so.., let’s try to represent this data in relational model i.e., in RDBMS design and also in Couchbase(NoSQL) design and will compare both to understand it better.

  1. Representing a Product info in the Relational model.
    1. In a relational database system, you must define a schema before adding records to a database.
    2. In the relational model, data is shared across multiple tables. The advantage to this model is that there is less duplicated data in the database.
    3. The problem with this approach is that when you change information across tables, you need to lock those tables simultaneously to ensure information changes across the table consistently.
    4. The following Entity-Relationship(ER) diagram represents the Product model and the reviews for that product with Review model and the relation between those two.  
    5. This is how we represent the data for a product and the reviews for that in the RDBMS.
    6. This way it will end up having two different tables one for storing the product information and other table is to store the reviews for that product.
    7. When we need to fetch a  product then it needs to query both the tables to return a Product model out of it.
    8. And when we need to add a new property to the Product/Review model then we need a respective ALTER statement for that PRODUCT/REVIEW table in order to sink with the application code.
    9. Some products have only a little information to store, irrespective of it RDBMS design will force to have null or empty values for all the other columns, which is not really required.
    10. These are the some the points to understand how the RDBMS design is little flexible for the development and agility.
    11. With RDBMS design we need to explicitly take care of the state of that model in DB whenever we add or remove a property to/from the model.
  2. Representing a Product info in Couchbase data model.
    1. In contrast, a document-oriented database contains documents, which are records that describe the data in the document, as well as the actual data. Documents can be as complex as you choose; you can use nested data to provide additional sub-categories of information about your object. You can also use one or more document to represent a real-world object.
    2. In Couchbase we could represent the data in the JSON format, below JSON represents the product state in Couchbase DB.
    3. In this way, the Couchbase can able to maintain only one document (like one record in RDMBS) for each product instead of maintaining as two different records in two different tables that are complex to maintain the state of each product.
    4. When we need to fetch a  product then it needs a single call to this product bucket (it’s like a Table in RDBMS)
    5. When we need to add a new property/remove an existing property to/from Product/Review model then it will need only an application level code change and no more schema changes required, so it’s like a dynamic change for the schema.
    6. This way in Couchbase the state of the application will depend on only the application code and not on the schemas and all that we do in RDBMS
    7. This way the application development is very fast and it does not require a downtime for any change to the models, and it provides great availability to the end users.
    8. The document-oriented approach provides several upsides compared to the traditional RDBMS model. First, because information is stored in documents, updating a schema is a matter of updating the documents for that type of object. This can be done with no system downtime. Secondly, we can distribute the information across multiple servers with greater ease. Since records are contained within entire documents, it makes it easier to move, or replicate an entire object to another server.
    9. It’s agiler when compared to RDBMS


Couchbase Server’s flexible data model and dynamic schemas enable frequent improvements to applications without downtime or schema migrations.