I think in general the SQL Server DBA’s of the world prefer that object names not have spaces embedded, and probably not be all upper case either. The spaces are a practical consideration, as soon as you use them you’re forced into bracketing the offending the name ([First Name]). There’s an option to auto add them in SSMS, but they’ve always seemed…noisy. I’ve long since stopped using them, and not really thought about it much since then, until recently I was using a third party grid control on a web page and noticed that it automatically changed ‘FirstName’ to ‘First Name’ for the column header. I’d been used to manually doing that and it was a nice labor saving touch.

I try to use column names that would be reasonable for a report, using FirstName instead of FName. Of course to a non-tech person even FirstName looks like a typo, but it’s not horrible. There’s no guaranteed win though, using “Marital Status” on a report instead of “MS” just wastes (sorta) display space when you just want to report the code (M, S, etc) rather than the literal. Using First_Name is a middle of the road approach.

So, for 15 minutes I’m questioning the no spaces rule. Is it really the right thing, or just what’s best/preferred by me at the expense of every developer and report writer in the company?

The alternative I’ve thought of is exposing a variety of “pretty” names for each column. At design time (and later) we could define the underlying column name as we prefer, but also define a super short version as well as a full length normal looking version. For example:

• True Column Name: FirstName
• Short Version: FName
• Long Version: Customer First Name

We’ve already got support for column level properties, would just be a matter of building maybe more direct support into the designer. Thinking really big, if we leveraged some of the .Net’ish syntax, we might do this:

select firstname.TrueName, firstname.Short, firstname.Long from table

Of course, just because I can think of an alternative doesn’t mean we need to build it. Definitely this can be done today without any language enhancements, but it would rely on convention and wouldn’t be widely supported across tools/components. Or we could ask for a parser that was smart enough to know when a space was part of the object name and not a delimiter.

Solving a problem that doesn’t exist maybe?

I think I’m content to stick with no spaces for now. Yet I still think that if spaces were painless for us the DBA’s, we’d use (or even mandate) them.