ReadWriteWeb has an article on non-traditional databases. It does a good job of explaining the good and the bad aspects of developing to a key/value database.

Among the bad is the lack of integrity support in key/value databases. I am not convinced this is a huge issue. I have seen production relational databases that do not have integrity constraints.

Data that violate integrity constraints cannot physically be entered into the database. These constraints don’t exist in a key/value database, so the responsibility for ensuring data integrity falls entirely to the application.

Legacy database systems require a data modeling process. Actually I see this as a downside. Typically as a project matures, the data model changes often. This requires changes to both the model and the supporting code. Key/value databases move the responsibility to the application and eliminate the time it takes for the modeler to update the model, change the database schema and communicate these changes.

One of the other key benefits of a relational database is that it forces you to go through a data modeling process. If done well, this modeling process create in the database a logical structure that reflects the data it is to contain, rather than reflecting the structure of the application.

Lastly, the author points out the multi-tenant limitations Google and Amazon put in place to prevent one user from overloading a non-traditional database in a shared environment.

Key/value databases are usually multi-tenanted, which means that a lot of users and applications will use the same system. To prevent any one process from overloading the shared environment, most cloud data stores strictly limit the total impact that any single query can cause. For example, with [Amazon’s] SimpleDB, you can’t run a query that takes longer than 5 seconds. With Google’s AppEngine Datastore, you can’t retrieve more than 1000 items for any given query.

What do you think, friends?

photo credit: -Renegade-