Stepping Up to the Plate

I spoke at a user group meeting just before writing this column. After the meeting, we did what IT people love to do when they're away from the office: We griped about our jobs. I've been taking an informal survey about who the DBAs and database application developers are in the real world, not what some ideal job specs describe. I've come to the conclusion that the two groups aren't that much different — at least in small shops.

A Small Shop

Small shops can get pretty database packages for smaller machines at reasonable prices these days. But they can't outsource for two major reasons. First, they don't have the money to spend; second, a small shop has to be more agile than a large mainframe shop. The money problem explains itself. The second reason takes a little thought: The small shop is probably specialized and has a small SQL server to avoid taking up expensive mainframe resources.

Back in the late 1970s, the rule of thumb for buying a minicomputer was to look for a $40,000 to $50,000 cost point. That is, if you could get a minicomputer, application programs, and personnel within the team to maintain them in that price range, the minicomputer was a better deal than adding the application to the mainframe. Studies at the time showed that the real cost of adding a new application to a mainframe — paperwork, cost of computer time, mainframe software, scheduling, and so forth — was pretty high.

In a Small Company

Today, this small shop is most likely the heart of an entire small company. Going back to my user group meeting, one of the attendees was in that boat. His company does lab work and makes the results available to customers via the Web. As with many small shops, the database is on a local server in the company office.

He got the DBA position by being a good programmer and saying, "I should learn SQL better" where his boss could hear him. The boss didn't offer to send him to SQL training classes — just gave him the job based on the idea that if he knew one programming language well, he must know all programming languages well. (In a lot of small shops, you're expected to pick up database skills by osmosis or magic and not miss a beat on your first job.)

The database was already in place and had been written by the last guy who got the job in the same, poorly reasoned way. The last guy left while performance was still acceptable, but now the system was a mess. This is an ugly truth in SQL that we don't talk about it. A bad schema and the resulting bad queries you have to write to work around it can run for a while before breaking under a growing data load. Good procedural code tends to scale in a linear fashion under data loads — twice the data takes about twice the time. A really good SQL query and schema can actually have a less than linear pattern — twice the data takes less than twice the time. But a badly designed SQL query decays by orders of magnitude — twice the data takes much more than twice the time.

Tarzan Vs. the Rhino

My first column in the trade press was called the "Rhino Algorithm" (Information System News — now InformationWeek, Sept. 8, 1980); it dealt with the scalability of algorithms and got its title from the old Tarzan movies where Tarzan avoided being run over by a rhino by simply jumping to one side at the last minute. A great solution when faced with one rhinoceros, but it doesn't scale well to a stampeding herd.

My new friend's company was finding that success was leading to more rhinoceroses at its door. A little bit of downtime led to a backlog that almost killed the company and showed it what a serious outage would do. A outdated lab report is useless at best and deadly at worst. Imagine your doctor saying, "If I had known that's what the problem was, I could have given him the antidote, and he'd be alive this morning!"

My friend told his boss that the entire database needs to be redone. The boss has explained that this isn't an option — time, money, existing application programs, and all the other usual suspects. Apparently, business failure, lawsuits, and possibly killing people are viable options.

Joe Celko is vice president of RDBMS at North Face Learning in Salt Lake City and the author of five books on SQL.