Worst Practice - Spaces in Object Names
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/awarren/worstpracticespacesinobjectnames.asp>http://www.sqlservercentral.com/columnists/awarren/worstpracticespacesinobjectnames.asp
-
also, not only table naming conventions, but field naming conventions. it is really tough to write queries that join two tables where they both have fields named "id" to join on. It gets even worse when you add more fields, joins, etc. True, you can alias columns and tables (a.id = b.id), but that is a pain and is avoidable by naming the fields the "right" way!
-
add to this, avoiding the use of non-alphanumeric characters, wildcards, etc...
eg: tblName%
Arrrgghh!!!!
Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface
--------------------
Colt 45 - the original point and click interface
-
I agree with this 100%
- Don't use spaces in table names
- Stick to alphanumerics, (preferably without the numerics unless you absolutely must)
- Don't use reserved words for tables i.e have a table called "Order" or "Exists"!
I think a "best practices" option should be added to YUKON so default naming conventions can be enforced. For example, pattern match object names.
-
I guess people do it for readability, but I've always used the '_' (underscore) if I've needed to put a gap between words in a table name.
eg. New_Table_Name
-
Totally agree - bad enough that data types can't be standardised across databases/programming languages, let alone adding nonsense like spaces and underscores to object names. Added to which, doesn't it contravene ANSI standard SQL, which would make it more difficult to port?
Jon Reade
Edited by - jonreade on 10/01/2003 03:52:31 AM
Jon -
I'm going to a follow up to hit on the object naming thing a little harder - you guys are right, spaces arent the only bad thing. Just particularly objectionalble to me!
Andy
-
Thank you! I have been fighting this battle for years! Nothing is as frustrating as writing out the query, or grabbing columns from the object browser, hitting execute and getting an error because I need brackets around some object. Egad! Just don't do it! Embrace the non-spaced object naming convention!
There are indeed many "worst practices" to avoid, but this is so easy to avoid.
-
I see no reason to use spaces for object names or column names. To me TableName is just as easy to read as Table Name and then I don't have to see those brackets which just cluter up the screen.
Robert W. Marda
SQL Programmer
bigdough.com
The world’s leading capital markets contact database and software platform.
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems -
I blame the practice on Access database users. Access allows this practice and then if the Access database has to be moved to SQL Server, those tasked with the move get bitten.
-
I agree. We should "never" put spaces in object names, whether those objects are tables or fields.
One reason is this 'Object Name' (one space) and 'Object Name' (two spaces) are two unique objects - try to tell them apart in a code listing!
However, it's easy to tell the difference between 'ObjectName' and 'Object_Name'.
-
>>I blame the practice on Access database users.<<
Poor, maligned Access users! 🙂
I came to SQL Server via Access, but I *never* used spaces in names.
On the other hand, I've inherited more than one SQL Server database that never existed other than in SQL Server but where the developer used spaces and all kinds of other no-no's.
In Access, I always use "camel-case", e.g., UniqueNameForTable, and continue this practice in SQL Server. My pinkie hates jumping to the underscore character, so whenever I have a say in things, I don't use underscores in any object names.
My own biased opinion... I think using underscores to break up a name is a bad habit left over from older systems that don't preserve case, such as the "O" word...
Best regards,
SteveR
-
Isn't camelcase uniqueNameForObject?
In any case, I completely agree. Spaces are a pain!!!! especially when scripting.
I'd expand this to include stupid folder names as well (#$%#^#$%$# Program Files folder)
Steve Jones
http://www.sqlservercentral.com/columnists/sjones
The Best of SQL Server Central.com 2002 - http://www.sqlservercentral.com/bestof/
-
As usual Andy, you have done a wonderful job writing your article! One of the first things I did when I got hired here was to create a SQL Best Practices document to help the people here to write better SQL. This is one of the topics I covered. Kudo's, and keep them coming 🙂
Gary Johnson
Microsoft Natural Language Group
DBA, Sr. DB Engineer
Gary Johnson
Microsoft Natural Language Group
DBA, Sr. DB EngineerThis posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed in this post are my own and may not reflect that of my employer.
-
quote:
I blame the practice on Access database users. Access allows this practice and then if the Access database has to be moved to SQL Server, those tasked with the move get bitten.Don't blame the Access database users themselves. Have you ever produced a database using the Access Database wizard and not had spaces in object names??
If blame is to be laid anywhere it should be with the producers of the product that not only allows it, but provides tools that direct you towards developing that way.
Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface
--------------------
Colt 45 - the original point and click interface
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply