SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Ideal Agile Database

By Phil Factor,

One of the pleasures in the life of a database consultant is to be able to tell a client that they don't need a relational database at all. Plenty of scientific applications don't need them nor do many social media or recreational applications. You are often much better off with a system that specializes purely in the requirements you have.

There are, of course, problems with this. You have to know your requirements in detail up-front. Sometimes, the team who are designing and building an application don't know, or have never thought about, the broad scope of their requirements in detail. They become excited by the speed at which a particular database system stores and retrieves object data, and make a quick gut-decision to use it. Only later do they realize that it is almost impossible to restore a backup, or that the data can be read via an 'exploit'. There have been several disasters where trading systems built on NoSQL have failed to realize the importance of transactionality.

The confusion happens because there is only one word in the industry to describe a database. Many of us use the term casually to describe any system that allows you to store and fetch data. The term 'database' comes with baggage, though. There is a general understanding that a database will allow more than one process to access the system simultaneously, can cope with recovery (Backup/Restore), security (is it possible to hack the data), access control (do users see just the data that is appropriate for them), transactionality (will it handle business transactions safely), isolation, resilience and performance. We can sometimes assume that anything that calls itself a database has all these qualities and it can come as an unexpected, unpleasant and expensive shock when it doesn't.

A relational database is a safe bet, particularly where you're not yet clear about your requirements. Now that they are offering in-memory optimization for tables, it is an even easier choice. If you run out of grunt with a relational database, it is usually for the happiest of reasons: your application is so popular that it needs a distributed architecture. Even then, you have an easy migration path. You can delegate much of your ETL, archiving and specialized processing to a NoSQL database such as Couchbase, or migrate to a hybrid system such as VoltDB.

What am I saying? Could it be that a relational database is so versatile and feature-rich that it is the ideal database for an Agile development? Certainly, it is safe to say that you need to have done plenty of architectural planning to be confident enough to select a NoSQL alternative that matches the requirements and priorities of your applications.

Phil Factor.

 
Total article views: 62 | Views in the last 30 days: 1
 
Related Articles
BLOG

Timewarp: What Is a Relational Database?

Relational?!? Move On, Geezer! Maybe you’re thinking that relational databases management systems...

FORUM

System databases

System databases

FORUM

Modeling relational databases

Modeling relational databases

FORUM

Connection of SQL Database on one main system with .NET application on multiple systems

Connection of SQL Database on one main system with .NET application on multiple systems

FORUM

Reorganize Index, Database Integrity check, Update Statistics required for System Databases

Reorganize Index, Database Integrity check, Update Statistics required for System Databases

Tags
 
Contribute