Still Falling Down

Still Falling Down

NoSQL vs. Relational

Well, first of all, I suppose I need to have at least one blog entry per year, so this one just makes it.

For the last few months, I’ve been putting more and more data structures into MongoDB instead of MySQL, and I just put a task into the backlog to move everything from MySQL to Mongo.

I’ve worked with relational databases since 1989. Moving to an RDBMS from the indexed filesystems on the mainframe was a huge leap forward. It represented the start of the shift from overnight batch processing toward realtime data. For those twenty years I’ve been reverential toward the database component of the apps I’ve architected. I’ve spent significant upfront time putting together highly-normalized layouts with the goal of limiting schema changes as the product concept matures. Having had to do database conversions of various types, I’ve always preferred code conversions, so the idea is to overdesign the database as much as possible, and let the code catch up.

So, last year the talk around NoSQL really starts to heat up. It just doesn’t hit home for me, though. Why should I change my strategy of a highly organized data structure and switch to a primitive key-store with no JOINs, no referential integrity, and no strong entity-attribute model? Sure, I can see some nice two-dimensional structures which would benefit from a high-speed data store, but that’s what I use memcached for, so what’s the big deal?

I decided to attend MongoNYC last May. It was convenient, it was cheap, so, why not?

I can’t remember which session I was sitting in. But during that session, it hit me on the head like a licensing renewal bill from Oracle. This is an Agile development tool. If one of the important ideas behind Agile is to get a meaningful demoable feature in front of a customer or feature owner as soon as possible, then what am I doing spending all this upfront time designing a database with a dozen tables just to represent the customer contact who receives our invoice? Why can’t the Customer record (document!) just have a list of contacts? I don’t need a Structured Query language to assemble all the pieces of the document because I never tore the document into pieces in the first place. I can start writing the code, dump the data into a document, and get my prototype up and running.

So fast forward 6 months, and NoSQL gets more and more ink every day. Some well-respected MySQL people are still asking the wrong question. I know that performance has been a potent motivator behind the growth of MongoDB and the other NoSQL implementations, but the big deal here, folks, is development. For the last decade the true costs of running software have been tipping drastically towards product development costs and away from hardware and systems software costs. Unless of course, you’re Twitter, and you want to handle 50 billion text messages per minute. But for those of us just trying to build useful apps, it’s pretty cheap to throw money at performance issues. Don’t get me wrong, I love the speed that Mongo gives me. But what’s going to hit my bottom line is that I can get features out the door without an environmental impact statement for the database.

And, finally, I’m just having fun using MongoDB. Yup, I’m still in this for the kicks.

Leave a Reply

Your email address will not be published. Required fields are marked *

© 2019: Still Falling Down | Easy Theme by: D5 Creation | Powered by: WordPress