Column names. Sigh. What a long and sordid history our industry has with column names, or “field” names if we go back far enough. In early days they were limited to eight characters, and all caps! It wasn’t unusual to have cryptic meaning squeezed into the first two characters of a name, so that one could categorize twisted column names to give them more meaning. MTCSTTOT might mean Midwest Territory Customer Total. That one is fairly self explanatory, but there were (there still are) much worse.
Then along came the standards committees, open systems solutions, and lots of vendors to “save the day.” Long column names (and tablenames and directory names, etc. etc.) were promised to “clear up everything.” And then what happened? ….we’ve all spent a decade and a half updating parsers, fixing bugs, and learning how to deal with Midwest Territory – Customer Total and how to let the system know that we weren’t aren’t trying to subtract “Customer Total” from “Midwest Territory”.
I used to be a purist. Long column names, short ones, numeric characters, punctuation…..let’s allow it all! Why be picky? Even reserved words shoud be allowed, provided they are in the proper context. Burden should be on the vendors to figure it out and get it right. A piece of me still feels that way, but it is getting beaten up by the realist. Practically speaking, it seems we’ve gone too far. Maybe it’s the increased integration and cross vendor pollenation (or confrontation) that has resulted in the trashing of such lofty goals, but there still isn’t a good enough standard that works across all platforms, all databases, all languages, all tools, all operating systems, and in every context. Recently I’ve watched multiple sites loose sleep over problems that ultimately came down to files not being found in strange directory paths, column names causing strange and misleading syntax errors because of special characters when used in a system that didn’t understand them, and incorrect results in a scenario that mis-parsed an expression. This was across tools of different vendors, and across different environments — increasingly a situation that occurs in many enterprises.
It’s an issue we have to live with. It’s not an easy problem to solve, obviously. I’d still like to see it resolved, but as long as we have lots of different software, lots of different skills and lots of different environments, the problem will continue to raise its ugly head. Long names seem to be “fairly” well supported, and adoption of the CamelCaseMethod that Java programmers are fond of seems to work well in most places. Spaces and strange characters, though, require better justification. Somewhere, somehow, they tend to still show up as thorns.
If you have to use blanks or strange characters in a column name, please document it. Document why you made the choice, so that it can be revisited and/or evaluated later. Document the places that you are using it, and most importantly, be sure to employ tools that will help you find it everywhere if something goes awry.