Modify schema vs modify documents
If you want to add attributes to a beer in a relational model, you must modify the database schema to include the additional columns and their data types. For document-based data, you would add additional key-value pairs to documents to represent the new fields in the document-oriented database.
The
other feature of a relational database is data normalization, which means that it breaks down data into smaller, related tables. The following figure illustrates this:
In the relational model, data is shared across multiple tables. The advantage of this model is that there is less duplicate data in the database. If you didn’t separate beers and brewers into different tables and have a 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 between tables, you must lock those tables simultaneously to ensure that the information changes in the table consistently. Because it also distributes 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 warehouse database, you can choose to have two different document structures: one for beers and one for breweries. Instead of dividing application objects into tables and rows, you would convert them to documents. Providing a beer document reference to a brewery document creates a relationship between the two entities:
In this example there are two different beers from Amstel brewery. Each beer is represented as a separate document and refers to the brewery in the brewery field.
If
you’re
thinking about moving your data from a relational database to a document-oriented database, or you’re considering Couchbase for your next project, we have plenty of tools to ease the transition.
Can I still write SQL queries?
Yes! Couchbase is the only NoSQL database with a full implementation of N1QL. Do you want to try it? The quick start with Couchbase 6.5 WebUI includes N1QL. You’ll be up and running in minutes. You can also try the N1QL online tutorial, an N1QL guided tour, and a sandbox interface, right in your browser.
What about ACID transactions?
At first, NoSQL databases did not support ACID transactions. However, that has changed. Couchbase now offers ACID transactionsHow
do I migrate?
There are many approaches to this. Here are some links for future research
:Data Model
- – Mapping MySQL
- How to use N1QL to migrate
- CBimport: a tool for importing CSV or JSON data
- Migrating data from MongoDB to CouchbaseHave
to Couchbase Server
data from Oracle to Couchbase
into Couchbase
more questions
?
Do you have a question about something not covered in this document? Ask in the Couchbase forums.
Summary
The document data model approach provides several advantages over the traditional RDBMS model. First, because information is stored in documents, updating a schema is a matter of updating documents for that type of object. This can be done without system downtime. Second, you can distribute the information across multiple servers more easily. Because records are contained in entire documents, it makes it easy to move or replicate an entire object to another server.
