SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Spaces in Object Names Revisited

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.


I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.


Posted by edwisdahl on 6 October 2009

I can't stand spaces in column names.  Same with key words as column names.  That being said, I try to use extended properties to give the database objects business names and display names where possible.  So, it should be pretty easy for the report writers and / or application developers to gather that information and use it instead of the physical names... I don't think that they do yet, but they could.

Posted by Steve Jones on 6 October 2009

I agree, spaces in object names are problematic. They work OK with fixed width fonts, but so many places are TTF that it's hard to tell where spaces are.

I think I like capitalizing first letters and removing all spaces.

Posted by Anonymous on 9 October 2009

Pingback from  Stylish Living Room Furniture Choices | Living Rooms | Domestic Furniture

Posted by Michael G on 20 October 2009

The use of spaces in SQL Server objects names are definitely problematic.  If you like to keep using names try resorting to using Access instead. :-p

Posted by Michael G on 20 October 2009

* spaces in names - oops :)

Leave a Comment

Please register or log in to leave a comment.