Search

Ted Dziuba made some waves recently with his blog post, “I Can’t Wait for NoSQL to Die”. There are a lost of posts like this with sensational titles that are actually well-reasoned, yet provocative posts. However, I do not think this is one of those posts.

There are many things I find wrong and/or disagree with in that post, but here are the three points I want to rebut from this article:

  • “Real” businesses use RDBMS’s. Businesses that use OODBMS’s aren’t real businesses
  • NoSQL programmers don’t think they need DBAs.
  • NoSQL is just a trendy fad, just like Ruby on Rails

1. Real businesses use RDBMS.

This sounds like No true Scotsman to me. “Walmart is a real business, Twitter is not”. What about NYTimes, EA, SourceForge, Facebook, Digg, Ricoh, Boeing, BMW, Merrill Lynch, Hertz, IBM, Intel, etc? I suppose they are the exceptions that prove the rule. I don’t think that relational databases “have lapsed their useful lifetimes”. I don’t agree that “MySQL was the perfect solution to everything a few years ago”. I don’t agree with any of the straw-men or false dichotomies that are sprinkled throughout the post.

2. NoSQL programmers don’t think they need DBAs

“Any company that has the resources to hire a DBA likely has decision makers who understand business reality” is just another version of the same No true Scotsman argument: companies that hire DBAs are smart, companies that don’t are dumb. However, the idea that NoSQL reduces or eliminates the need for DBAs is not an uncommon one; I’ve even seen that attitude when talking about ORMs. But using TDD doesn’t mean you don’t need QA, and using NoSQL doesn’t mean you don’t need DBAs. On the contrary, I’d want to consult with DBAs more when making a decision about what RDBMS and/or OODBMS to use. The above quote begs the question that a company would not hire DBAs because OODBMS’s don’t need them: nonsense.

3. NoSQL is just a trendy fad, like Ruby on Rails

Those kids and their ruby rails and their object databases. You leave the real enterprisey businessy work to us, and you can keep your tweeters and your hula hoops and your baggy pants… I find this point to be especially rude, flippant, and just plain wrong. I’m not a big fan of Ruby as a programming language, I’m not good at it, and I probably wouldn’t use it given the choice. But it would be irresponsible to not recognize the value that the ideas in Ruby/Rails have brought to the development forefront, and the huge influence it’s had on other languages and frameworks. Talented developers are using Rails to deliver real business value every day. I see no reason why NoSQL can’t deliver similar value, get us to think about data differently, and contribute a real option when making technology decisions.

So, Groves, you think NoSQL is better than SQL, and is going to take over, then?

No! All I’m saying is this: Right Tool, Right Job. NoSQL products are just another tool for delivering customer value, and achieving a desired result. They are not the proverbial “every problem is a nail” hammers (and the same goes for SQL products too). In fact, some people have even been so crazy as to suggest that NoSQL and SQL be used in tandem to take advantage of the strengths of each one. Crazy talk, I know.

So what’s the deal, why does this guy hate NoSQL so much?

Who knows? Maybe he doesn’t understand them, is afraid of them, has too much personal investment in relational databases (i.e. a fanboy), or has seen them applied wrongly too often. Maybe he is a DBA who is afraid of becoming obsolete (see above). Or maybe he’s right, and RDBMS is the right tool for most every job. But please, don’t come to that conclusion based on a fallacy: analyze the problem, the environmental factors, the suitability of the solution, the long-term impact, the constraints, and use the Right Tool for the Right Job.

2 Responses to “RTRJ”

  • Jesse Riley says:

    I tend to agree. Sometimes using a "no database" is perfect and exactly what you need and will support anything you want that system/app/whatever to do. I also think there’s a line that can get crossed where it no longer supports the needs of the system and I think that may be your underlying point.

    As many apps grow into monsters, the initial idea of "well it’s going just to do blah" is no longer valid so you can’t treat it as a one trick pony it once was. Maybe now it’s a 35 trick pony and you simply need a bigger stable, maybe an arena with grandstands, a ticket booth and a parking lot. Trying to make the old iron fence corral may be a wonderful romantic idea (ooo call me) but it it should only be used as a picture on the wall of "remember when".

    I would even go a bit further with "right tool, right job" and add "at the right time".

  • mgroves says:

    Absolutely. Time is an important constraint to consider. Let’s say db4o may be the right tool for app X, but all the devs in your shop only have MySQL experience. If app X is critical and needs to be out the door, there may not be time/resources to ramp up to db4o, making MySQL the right tool for the job at that time. Then maybe db4o can be used later on an app that isn’t as time sensitive.

Leave a Reply