Slowdog

This is going to make me sound like an old man (OK, right, I am old. So, suck it.), but these two posts alternately scare me and let me know that I’ll have work going into the future as a DB developer.

In the first post, Chris Moos describes a problem he’s having with queries performing badly, doing full table scans over a 12M row table. His answer: partition the table. So, Chris, first off, let’s talk about this 12M row table. Does it really have to be so long? Can something be done (other than partitioning) to make it smaller. Second, um, have you heard of indexes? They work pretty well. (Not that our tables are all that big, but) We have tables well over twice that long (and they sound like they are much wider as well), and get good response on queries using the indexes. Why, why, would you go with something as complicated as partitioning, when there’s other approaches that should be tried first.

The second post describes how, with the coming of more NoSQL solutions, MySQL doesn’t need to be used to store data objects as blobs anymore. A solution that earlier “made perfect sense.” There’s many arguments to the design of data objects, and I’ve been a part of many of them. I have big problems with the storing of objects as blobs which I won’t go into here. If that’s something you want to do, fine. But to do that using MySQL (or any relational DB is just plain stupid). And, it never made any sense, let alone perfect. When picking tools, familiarity with the tool is only one aspect. A much larger aspect is whether it’s the right tool for the job. MySQL has a lot of strengths, but the way it stores blobs is not one of them. And, the NoSQL solutions aren’t really new. Object-Relational, Object, and Document-based DB’s have been around for a long time. Not to mention, just using ye ole file system.

My design steps?

1. Choose the right tools and be able to defend why you’re choosing them.
2. Keep things simple. Only get more complicated as the product/users dictate.
3. Think ahead, but not too much ahead. Are you designing for today, or the future? Don’t want to go crazy as who knows what the future holds, but try to at least think 3-6 months ahead.
4. Be ready to redesign something. Don’t hold onto a design for reasons of pride. It doesn’t work, then it doesn’t work. It’s only data, it’s movable.