NoSQL and Document-Oriented Databases

by Toan T
Any database that does no support the SQL language is known as an NoSQL database. NoSQL was inspired and created based off Lotus notes, a program that was co-created by Lotus founder Mitch Kapor and Microsoft chief architect Ray Ozzie as a personal productivity tool. Lotus notes was never thought to be a database application; it was more thought of as an alternative to Microsoft Outlook. However, Lotus Notes included a back-end database that was optimized for sorting and working with complex documents. The program ended up inspiring the approach taken by two of today’s best-known NoSQL systems: CouchDB and MongoDB. What makes NoSQL so different is that the database systems store information not as normalized relational tables, but as documents in rich self-describing structure. It uses a  variant of JavaScript Object Notation which is similar to XML to store the documents. This approach offer more compact storage and lower processing overhead. Document databases primarily appeal to developers for the very reason that relational databases don’t. The RDBMS entity-relational data model is usually inherently different from the object-oriented model of the modern programming languages. It impacted programmer productivity by the need of translating objects back and forth from the database to the program. In document database, the document can map almost directly to the programming language’s class structure. This makes programming easier, but does raise issues of data integrity, since some data are almost inevitably duplicated. Document databases also promise a more flexible approach to schema changes. In an RDBMS, any change to the data model is costly: programs need to modified, then deployed in conjunction with the schema change. In a document database, an application document can be modified whenever it wants. That is a good thing and is also a bad thing since it can be a risk to have inconsistent or obsolete document structures as a result of application version changes in document databases. The document model also have some scalability features. Since all the data needed for most operations is held in a single document, there is no need for joins and multi-object transactions. Avoiding joins and transactions eases clustering issues.

When we are think about databases, the words that come to mind is always relational and SQL. Relational database has help us store database very efficiently and securely but that does not mean it will fit in with everyone’s applications. NoSQL is still maturing at its current life with its issues of data integrity and availability. It is also unknown how it will outperform the traditional SQL approach when it comes to large scale databases but it does provide some features that do seem very appealing. I find this article to be somewhat relevant to the class even though we did not talk about NoSQL. As we are learning SQL, knowing and understanding the alternatives and how they are compared to the traditional approach is also a good way to understand how data can be stored in different ways.

Source: arrison, G. (2010). NoSQL and document-oriented databases. Database Trends and Applications, 24(4), 32-32. Retrieved from 

Image Source: