Previously, I presented some types of databases:

Key-value stores: data is stored as key-value pairs such that values are indexed for retrieval by keys. These systems can hold structured and unstructured data. An example is Amazon’s SimpleDB.

 

Column-oriented Databases: contain one extendable column of closely related data rather than sets of information in a strictly structured table of columns and rows as is found in relational databases. The ColumnFamily databases stem from Google’s internally-used BigTable. Some other examples are Cassandra, HBase, and Hypertable.

 

Document-based Stores: data is stored and organized as a collection of documents. Users are allowed to add any number of fields of any length to a document. They tend to store JSON-based documents in their databases. Examples of document databases include MongoDB, Riak, Apache CouchDB, and SimpleDB.

Find below some applications and uses

Apparently, document databases are often best when dealing with collections of similar entities.

ColumnFamily (column-oriented) databases seem to be best when scalability (particularly write scalability) is the main issue. The tradeoff is that developers must write more complicated code in order to do certain things explicitly. Graph databases (another type of NoSQL database), are often best in cases where the manner in which entities are related is very important.

In an SQL database, adjustments involving updates to schema and already stored data often cause problems whenever unanticipated changes need to be made to initial database designs. I have always wondered how upgrades to applications that are already in use can be made, especially when they involve making changes to database tables that already contain data. NoSQL databases seem to be the answer to this dilemma.

It is quite obvious that RDBMS is better at some things, particularly reporting. There are already a large number of reporting tools built around RDBMS. It is important that we use the right tool for each job. It is only by doing this, that we can produce software that works best in the situations in which they are intended to be used.

NoSQL databases, when used appropriately, can offer real benefits. However, caution should be exercised when adopting new technology. Everyone generally needs to be aware of the limitations and issues that are associated with these databases. This is especially important for enterprises.

Apparently, the best days of relational databases are now far behind, but these systems are not likely to die anytime soon. In fact, NoSQL databases are not likely to replace relational databases, but instead would find their own niche in certain types of projects. As Dave Kellogg has rightly stated, some of the NoSQL hype is actually an over-reaction to the current situation where a small number of RDBMS vendors control the vast majority of the database market. Nevertheless, some of the NoSQL hype is also a reaction to the technological inadequacies of relational databases as well as the conceptual and technical difficulties in programming on them.

I intend to employ heavy use of a NoSQL database (probably MongoDB) in a new project of mine. I believe it just might solve some of my worries, even though I know it would create some new ones as well.