The NoSQL Movement: The Object – RDMBS Incompatability
I could prove that I’m a dinosaur and say “are you out of your mind — No SQL?” But then, I would be the one out of my mind.
I’ve always used relational databases and SQL. In fact, SQL could probably be called my second language. And while I don’t have the gripes that others may have with the language itself [http://www.kellblog.com/2010/02/24/the-database-tea-party-the-nosql-movement/], relational databases do come with a bag full of limitations and challenges. I’ll tell you my gripe.
My biggest gripe is that I believe in object oriented programming, and RDBMS doesn’t play nicely in the OO sandbox. Now of course, you could write your own data tier that calls stored procedures, or that has prepared statements. But this is asking developers to write in a second language for your application. This leads to ORMs, and for anybody who hasn’t worked with me, know now that I hate them for anything beyond simple CRUD operations.
But the biggest problem is effective modeling. You cannot effectively model some object or hierarchical relationships with RDBMS. For example, try to model n-deep dynamic menus in a relational database. Each menu node has a parent, and each menu node falls within some order relative to the other items under the same parent.
Example Menu Hierarchy
This is actually fairly easy to model in an RDBMS, but it is not very effective. Each node has a parent node (except for the root node, which I left out for the sake of this example), and each node has a numeric ordering.
Data Model for a Menu in a RDBMS
So here comes the problem. What’s the SQL for selecting out your menu structure? Since you do not know how deep the structure is (n-deep), you could do this with a crazy loop and some recursion.
- Get the root node [SELECT * from MenuNode where nodeParentNode is null]
- Get all of the first level nodes [SELECT * from MenuNode where nodeParentNode=0 ORDER BY nodeOrder ASC]
- For each node returned, get it’s children, recursively
For the example menu hierarchy above, this would result in 1 SQL call to get the root, 1 call to get its children, 1 call for each of those 4 children to look for their children, two calls to get the children of D3a and D3b, two calls to get the children of D3bA and D3bB, and one call to find the children of D3bBi. SQL round trips are expensive, and this is a lot of calls for a small menu. This does not scale at all. And this doesn’t even address the problem of maintaining order within each level of the hierarchy. Of course, there are other ways to skin this cat. nodeOrder could be replaced with nodeAbove, using more of a linked list type of structure, but that doesn’t work well either. It would probably be more efficient to grab all the nodes in one sql call, and put them back together as you load them into a proper data structure, which in and of itself will take processing and time.
The bottom line is that it’s not a natural fit.
So, NoSQL people, tell me how you would do this using other tools? CouchDB? MongoDB? Cassandra? MarkLogic? I presume this problem has been largely solved. I still don’t believe that RDBMS is a bad tool. You need to use the right tool for the problem you’re trying to solve, and be careful to minimize the total number of data persistence tools in your organization.
Google's New Math
Do you see a problem here? How does Google get away with this? I’m pretty sure that if I made this mistake at work I would catch all bloody heck. But then again, I’m not Google.
[polldaddy poll=1362581]
Pulling Out the Monkey Wrench
You’ve heard it before. And probably many times, too. “They just threw a monkey wrench in my plans.”
Okay, so what now? Sorry for stating the obvious, but pull it out. I learned, long ago, the difference between those that succeed and those that fail. Those that succeed are the ones that can find a workaround, and don’t quit until they do. Here’s some advice for how to do it.
- Focus on the problem you’re trying to solve, not the problem caused by the wrench.
I find that most wrenches aren’t problems at all, if you focus on the real problem. Problem-solvers often get fixated in the details of their solution, and forget to consider other potential solutions. I’ve seen this just about every week of my career, be it a technical problem or a business problem. For example, let’s say you’re designing a car, and decide that it needs more battery power than any existing battery can provide. Instead of trying to solve the problem of creating the most powerful car battery, why not see if you can use a two-battery solution? - Don’t Go it Alone
You don’t need to be a hero, and you’re not the smartest person you know (usually). And even if you are the smartest person you know, others may be able to see things from another angle. Don’t be afraid to ask for help; even from those who may not be experts in the area of your problem. In fact, that can often be an advantage. - Don’t Get Discouraged
This is easier said than done. But depression and frustration inhibit creativity. If you find you’re getting down over a problem you’re trying to solve, it may be a good time for a small diversion. I’m not suggesting laziness or avoidance, but something to help you walk away and return with a clear mind. For example, if you’re editing your own writing, it’s best to walk away for a while and come back. Otherwise, your mind may recall what you were thinking while you’re reading, and inadvertently ignore mistakes seen with your eyes. Go watch a hockey game instead, and come back later. - Extend Your Circle
You asked your co-workers and friends, but they couldn’t help. Don’t stop there. Try your LinkedIn network (and build it up before you have a problem in the first place). Ask you friends and co-workers to ask friends, or to give you names of people who could help. Hire a consultant. Post your problem on bulletin boards. Hold a brainstorming session, and invite outsiders (offer beer and pizza).
The bottom line is don’t quit. Keep attacking the problem, and keep looking for help, but don’t let it consume you 24×7. Same of these things may seem obvious, but when the wrench is in the machine and the pressure is on, they could be forgotten, so it’s good to keep this handy.
Please post your suggestions too!
