I wrote this editorial about bad design based on some real world experiences. It’s a fun story, maybe  even borderline ridiculous, but the truth is the database design wasn’t as big a problem as you might expect. We got rid of some of the duplicate data bulk caused by the ‘seach columns’ (an upper case copy of the actual data) and yes, it required more horsepower than it should have, but only because of the api cursor usage. When we later built a similar application on the same data structure using better data access (procs), it ran better and the remaining problems were usually more about how we accomplished a goal than the design itself.

Ten years later those core tables are still there, still working.

Good design is worth doing, but a lot of times what we call ‘bad design’ doesn’t matter as much as we think it does. I’d take a good normalized design with ugly primary keys over a highly denormalized design with integer keys any day.

On any given day we do the best we can. Sometimes that means fixing or work around problems created by those with less knowledge or different styles than we have. I try to neither complain nor gloat in such cases, they made something work, now they are asking me to make it work better – that’s what I do!