Beyond Relational Databases

14 Feb

I am no expert with databases, however I can definitely see scalability issues that relational databases provide when needed to grow beyond one database. Relational databases also are strongly typed and explicit relationships exist between entities. This explicit relationship specification and strong typing often requires developers to write migration scripts which can be a pain and could potentially be avoided or minimized.

There is an interesting article: http://www.readwriteweb.com/archives/is_the_relational_database_doomed.php which discusses the benefits of key-value databases or cloud oriented databases.

Unfortunately most of these databases are in beta and the standards between them are lacking, but I can definitely see from my experience developing payroll software that a key-value database would help us in many areas.

The down sides to key-value databases are that they are weakly typed and hence there is no schema which means you can get bad data in the database, meaning that code has to deal with that possibility, which could lead to more mistakes. I do feel however that weaker typing and not specifying relationships between entities is the way of the future because if we look at C# and other modern languages we can notice a trend of moving towards more weakly typed languages.

I do prefer a strongly typed language currently however as technology progresses I can see that dynamic typing will lead to more general code that will be more flexible to change. Currently my biggest concern is that dynamically typed languages are prone to catching errors at runtime rather than compile time which is a blow for software reliability. I am confident that this can be overcome.

It is important to state that there is an overhead in specifying types/schemas and converting between types. I also think that currently developers can make assumptions in strongly typed languages that objects will be populated in a way that they expect which sometimes is not the case. With dynamically typed objects this assumption would not be exercised as it would soon become clear that less can be assumed. The immediate development areas of .NET CLR 3.5 and 4.0 show that functional programming and dynamic objects are the current direction. I also like the hybrid approach that .NET is creating by using the power of strong typing and providing facilities towards gradual introduction of dynamic typing. This will hopefully allow for existing functionality that applies to strongly typed objects to be used against dynamically typed objects.

Advertisements

One Response to “Beyond Relational Databases”

  1. Daniel April 15, 2009 at 10:33 am #

    Having no schema is the entire point of using this form of development, it’s not a drawback it’s a strength. If you’re trying to scale an application to massive levels, fetching a single record with all the data in it (key-pair is best used when denormalised) is the most performant you can get.

    When it comes to rapid development, there is nothing quite like the speed at which you can alter/adjust/try new ideas when there is not schema to break or mess up.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: