So, I was responsible for a pretty unfortunate bug today — no way around it, I messed up. It was classic — there was a “TODO” block where I meant to come back and finish some code, and no doubt got distracted by some very valid crisis.

Fortunately, it was caught before it affected production data, but it was in test, and visible, and it was scary that it had gotten that far.

But I couldn’t help but be bitter about how that block of code came to be in the first place: the code that contained the bug was part of an elaborate scheme designed to work around joining to a particularly large table in certain circumstances.

Now, it’s big data (well, at least tens of millions of rows) …we have to do what we can for efficiency. But it made me slightly bitter that the more we optimize for relational databases, trying to eke more and more performance, the farther we move from a clear data model, and the less we’re using the “R” in RDBMS. We go through contortions, and in the process introduce bugs.

I’m not sure who that might be a lesson for, but perhaps if anyone is dead-set on using a tried-and-true RDBMS to avoid bugs in newer systems, whether MapReduce or a “NoSQL” store, it’s worth noting that there is some tradeoff here: bugs in the data store in question vs. bugs you introduce into your own code due to the increased complexity as you contort your data model to make it scale where you need it to go.