I read an interesting article in ReadWriteWeb.com which i follow daily. It is a good idea to take a look at the article. I paste first part of the article here.
Recently, a lot of new non-relational databases have cropped up both inside and outside the cloud. One key message this sends is, “if you want vast, on-demand scalability, you need a non-relational database”.
If that is true, then is this a sign that the once mighty relational database finally has a chink in its armor? Is this a sign that relational databases have had their day and will decline over time? In this post, we’ll look at the current trend of moving away from relational databases in certain situations and what this means for the future of the relational database.
Although fashions come and go in software development, some things stay remarkably constant. One of these is the use of databases. You may be wonderfully up-to-date with an AJAX Web interface or the latest whizbang Windows user interface, but under the covers, you’re probably still pumping data in and out of a database, just as we all did a decade or more ago. That makes it all the more surprising that developers are still making the same database mistakes that date back to those good old days of Windows 95 and before. Perhaps it’s just that most of us learn to use databases on the side, rather than really studying them. In any case, here are my nominations for the biggestmistakes that I see over and over again.
Choosing the Wrong Database
Not all databases are created equal — which means before you do anything with a database, you have to pick the appropriate database. Time and again I’ve seen Access databases groaning to bear the load of huge data sets that would have been child’s play for SQL Server, or harried users trying to pay for and set up SQL Server to hold a few hundred rows of data. Broadly speaking, there are three tiers of databases in the market these days: desktop and embedded databases suitable for smaller tasks, “Express” versions of the major players that are good up to a few gigabytes of data, and the truly enterprise databases like SQL Server, Oracle, and DB2 that can handle just about anything you can throw at them. Before you do anything else, you need to make some realistic estimates about the amount of data that you’ll be storing and pick the appropriate product to do the storage. Continue reading