Comparing Document Databases and Relational Databases

In a relational database system (RDBMS) you must define a schema before adding records to a database.

By contrast, a document-oriented database contains documents, which are records that describe the data in the document, as well as the actual data. In shorthand, we tend to call these "document-oriented" databases a "document database or a NoSQL database" or "NoSQL document databases"

Schema vs Documents

The schema is the structure described in a formal language supported by the database and provides a blueprint for the tables in a database and the relationships between tables of data. Within a table, you need to define constraints in terms of rows and named columns as well as the type of data that can be stored in each column.

In a document DBMS (database management system), documents can be as complex as you choose; you can use nested data to provide additional sub-categories of information about your object. Also, when utilizing this type of document storage database, you can use one or more documents to represent a real-world object.

Example

The following compares a conventional table with document-based database objects:

In this example, we have a table that represents beers and their respective attributes:

ID
Beer Name
Brewer
Bottles Available

The relational model conforms to a schema with a specified number of fields which represent a specific purpose and data type. The equivalent document-based model has an individual document per beer; each document contains the same types of information for a specific beer.

In a document-oriented model, data objects are stored as documents; each document stores your data and enables you to update the data or delete it. Instead of columns with names and data types, you describe the data in the document, and provide the value for that description.

Modifying Schema vs Modifying Documents

If you wanted to add attributes to a beer in a relational model, you would need to modify the database schema to include the additional columns and their data types. In the case of document-based data, you would add additional key-value pairs into your documents to represent the new fields in your document-oriented database.

Data Normalization

The other characteristic of a relational database is data normalization–this means you decompose data into smaller, related tables. The figure below illustrates this:

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. If you did not separate beers and brewers into different tables and had one beer table instead, you would have repeated information about breweries for each beer produced by that brewer.

Normalization and Scaling

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. Because you also spread information across a rigid structure, it makes it more difficult to change the structure during production, and it is also difficult to distribute the data across multiple servers.

Documents and Scaling

In the document store database, you could choose to have two different document structures: one for beers, and one for breweries. Instead of splitting your application objects into tables and rows, you would turn them into documents. By providing a reference in the beer document to a brewery document, you create a relationship between the two entities:

In this example there are two different beers from the Amstel brewery. Each beer is represented as a separate document and references the brewery in the brewer field.

Making the Switch to Couchbase

If you are thinking about moving your data out of a relational database and into a document-oriented database, or you are considering Couchbase for your next project, we have many tools to ease the transition.

Can I still write SQL queries?

Yes! Couchbase is the only NoSQL database with a full N1QL implementation. Want to try it out? The Quickstart with Couchbase 6.5 WebUI features N1QL. You'll be up and running in minutes. You can also try the online N1QL Tutoriala guided tour of N1QL and a sandbox interface, right in your browser.

What about ACID transactions?

Early on, NoSQL databases did not support ACID transactions. However, that has changed. Couchbase now offers ACID Transactions

How do I migrate?

There are many approaches to this. Here are some links for further research:

Summary

The document data model 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. Second, you 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.