In defence of the RDBMS: Development is not slow. You just need better tooling.

I pride myself on being a real world software developer.

Anything that I publish in this blog is a result of a some real world coding. I don't just play around with small, unrealistic demoware applications. I write real world applications that get used by lots of users.

With experience comes wisdom, and in software part of that wisdom is knowing when to employ a certain technology. There is almost never a right or wrong answer on what technologies you should be using on a project, as there are plenty of factors to consider. They usually include:

• Is technology x supposed to be the right tool for this job?
• Do we have the knowledge to work with and become productive in technology x within the scope of the budget?
• How mature is technology x?

The above questions will even have varying importance depending on where you are currently working. If you are working at an agency, where budgets must be stuck to in order for the company to make a profit, and long term support must be considered, then the last two points from the above have a greater importance.

If you are working in house for a company that has it's own product, then the last two points become less important.

Just about the only wrong reason would be something like:

• Is technology x the latest and greatest thing, getting plenty of buzz on podcasts, blogs and twitter?

This doesn't mean you should be using it on all projects right now. This just means that technology x is something that you ought to look into and make your own assessment (I'll let you guess where it might be on the technology hype life cycle). But is this project the right place to make that assessment? Perhaps, but it will certainly increase your project's risk if you think that it is.

One of the technologies that we are hearing more and more about are NoSQL databases. I won't go into explanation details here, but you should be able to get a good background from this Wikipedia article.

Whilst I have no issues with NoSQL databases, I do take issue with one of the arguments against RDBMS's - that development against them is slow. I have now seen several blog posts that have argued that developing with a NoSQL databases makes your development faster, which would imply that developing against a traditional RDBMS is slow. This isn't true. You just need to improve your tooling.

Here's a snippet from the mongo db "NoSQL Databases Explained" page:

NoSQL databases are built to allow the insertion of data without a predefined schema. That makes it easy to make significant application changes in real-time, without worrying about service interruptions – which means development is faster, code integration is more reliable, and less database administrator time is needed.

Well I don't know about you guys, but I haven't had to call upon the services of a DBA for a long time. And nearly all of my applications are backed by a SQL Server database. Snippets like the above totally miss a key thing out - the tooling.

Looking specifically at .net development, the tooling for database development has advanced massively in the last 6 years or so. And that is largely down to the plethora of ORMs that are available. We now no longer need to spend time writing stored procedures and data access code. We now no longer need to manually put together SQL scripts to handle schema changes (migrations). Those are real world huge development time savers - and they come at a much smaller cost as at the core is a well understood technology (unless your development team is packed with NoSQL experts).

Let's look specifically at the real world use. Most new applications that I create will be built using Entity Framework code first. This gives me object mapping and schema migration with no difficulty.

It also gives me total control over the migration of my application's database:

1. I can ask Entity Framework to generate a script of the migrations that need to be run on the database. This can then be run manually against the application, and the application will even warn you at runtime if the schema is missing a migration
2. I can have my deployment process migrate the database. The Entity Framework team bundle a console app that can be packaged up and called from another process - migrate.exe
3. I can have my application migrate itself. That's right - Entity Framework even allows me to run migrations programatically. It's not exactly hard either.

My point is this: whilst the migrating of a schema may not be something that you would need to do in a NoSQL database (although you would need to handle these changes further up your application's stack), making schema changes to an RDBMS's schema just isn't as costly or painful as is being made out.

Think again before you dismiss good ol' RDBMS development as slow - because it hasn't been slow for me for a long time.