Naming Convension

Question

Post reply

Naming Convension

Orion Pax

SSC Eights!

Points: 824
More actions
December 13, 2007 at 8:42 am

#182014

Hi Guys,
I'm busy setting up a naming convention for our organization. The question I have for everybody is:
Is it bad practice to use "." in the name of an object if the object does not have an owner?
E.g.
Primary Key: PK_Customer.ID (PK_{TableName}[.{ColumnName}])
Foreign Key: FK_Customer.ID_Gender__Gender.ID (FK_{TableName}[.{ColumnName}]__{ReferenceTableName}[.{ColumnName}])
Index: IX_Customer.CustomerCode.CustomerName (IX_{TableName}[.{ColumnName}])
What do you guys think? If these objects are references they should always be enclosed in brackets in any case. E.g. INNER JOIN Customer WITH ([IX_Customer.CustomerCode.CustomerName]) ON xxx
I've done some testing and SQL doesn't seem to mind :p

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply

ChiragNS One Orange Chip Points: 26137 More actions · Answer 1

have'nt seen people using "." in their object names.

Most important thing with naming conventions is that once you have decided on a convention stick to it.

"Keep Trying"

rajankjohn SSCertifiable Points: 5061 More actions · Answer 2

I feel an underscore (_) may be better in place of the (.) to avoid confusions 🙂

Steve Jones - SSC Editor SSC Guru Points: 736063 More actions · Answer 3

Steve Jones - SSC Editor

SSC Guru

Points: 736063

January 9, 2008 at 9:52 pm

#766465

I use mixed case, like

create table MyTableForSales

Ross McMicken SSCarpal Tunnel Points: 4435 More actions · Answer 4

We use the underscore _ character as a separator. Using periods can lead to confusion, given that other programming languages use them as separators for actions on objects. I hate using brackets on names, as forgetting to do so can lead to unintended consequences, and they make the code less readable.

Jeff Moden SSC Guru Points: 1004284 More actions · Answer 5

I'm with Steve... I use mixed case... it enforces capitalization and it's easier to hit the shift key than it is to hit the underscore when typing.

I agree with the others... never ever use periods, dashes, spaces, etc in any object name. In fact, I avoid all special characters because you can never tell when Microsoft may decide to start using one to mark special system objects.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Andrew-566477 SSC Veteran Points: 229 More actions · Answer 6

Periods are used to seperate domains, ie owner, database, table and column. IMHO its a very bad idea to use it as part of an object name. In fact, while its there for a purpose, it is uncommon for people to use [] when addressing an object. For that reason alone I would steer clear of any name (or convension) the requires you to use it unless you are going to enforce the use of [] around all objects.

Cheers

Andrew

Stephanie J Brown Hall of Fame Points: 3896 More actions · Answer 7

I agree, no periods in names, and no spaces either (hate the brackets - they are ugly and take up unnecessary space). I always use mixed case, and am a fan of the underscore where it makes sense to separate a field name - such as when several fields are grouped together.

IMHO, the point of naming conventions is to make it easy for the next person (or yourself 6 months down the road) to be able to determine some basic information about the field and its data simply by looking at the name. Sucinct Clarity is my personal goal for field names. As in:

Clarity_Concise -or- ClarityConcise

Clarity_Brief -or- ClarityBrief

Clarity_Compressed -or- ClarityCompressed

Clarity_Girdle -or- ClarityGirdle :hehe: (see dictionary.com...succinct)

Here there be dragons...,

Steph Brown

dbajunior SSCrazy Points: 2307 More actions · Answer 8

Adding to prev posts, I like to include module type as well:

tblEmployee_Profiles, vwEmployee_NameList, prcEmployee_Update

Orion Pax SSC Eights! Points: 824 More actions · Answer 9

Thanks for all your responces.

I agree with not using periods, spaces or any special character for object names. But as you might have noticed none of these (except for index names, and this should be very seldome) are actually use as part of a T-SQL statement. None of these are tables, views, functions, triggers or stored procedures. Only primary keys, foreign keys, indices and well constraints in general.

The only time square brackets will be required is when a developer forces a specific index to be used. E.g.

SELECT P.FirstName, P.LastName[, n]

FROM Person P (index = [IX_Person.FirstName.MiddleName.LastName])

Or, when the database is scripted. E.g.

CREATE INDEX [IX_Person.FirstName.MiddleName.LastName] ON Person (FirstName, MiddleName, LastName);

I already have a naming convension for all other objects. I just think it's so much easier detemining what [FK_OrderDetail.ID_Order__Order.ID] does versus [FK_OrderDetailIDOrder_OrderID]...

So what do you guys think?

GSquared SSC Guru Points: 260824 More actions · Answer 10

I use camel-case for table names, and use underscores in the names of procs where I would use a period if it were an OOP language.

For example:

Customers

CustomersEmail

would be tables. One with customers in it, one with the e-mail addresses of the customers.

Customers_Sel

CustomersEmail_Ins

would be procs for selecting (Sel) from Customers, or inserting into CustomersEmail (Ins).

Of course, many procs, functions, etc., access more than one table, so I generally use the highest level object as the first part of the proc name, then the function the proc does. "Customers_Ins" would thus be a proc for adding to the customers data, and would probably insert into Customers, CustomersEmail, CustomersPhone, CustomersAddresses, and any other related sub-tables used to define customers.

This makes it very easy in Management Studio to find all the procs that are, to one degree or another, "methods" for the customer object.

The funny part is, I developed this naming convention years before I even knew what OOP was. Parallel evolution, I guess.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Matt Miller (4) SSC Guru Points: 124210 More actions · Answer 11

Nope - still wouldn't use periods. The fact that it would only rarely end up in T-SQL doesn't much change what others have already mentioned in my mind.

Of course - it's YOUR naming convention, so do as you wish with it.

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

GSquared SSC Guru Points: 260824 More actions · Answer 12

On index names, I use a three-character code to indicate the type of index, then the table name, then a description, separated by underscores.

E.g:

IDX_Customers_Name on dbo.Customers(LastName, FirstName, MiddleName)

CID_Customers_Name on dbo.Customers(LastName, FirstName, MiddleName)

UID_CustomersEmail_Email on dbo.CustomersEmail(EMail)

UCI_CustomersEmail_Email on dbo.CustomersEmail(Email)

IDX = standard index

CID = clustered index

UID = unique index

UCI = unique clustered index

(Of course, some of my examples are mutually exclusive, I just used them as examples.)

I find this very easy to read, probably because I created it myself and have been using it for years. Others may not find it as useful, I don't know.

This violates my "use the table name as the first part of the object name" rule, but I started using it before I'd really codified the rest of my naming convention, and it's too entrenched in my mind to change easily. Given the chance, I'll change it to Table_Columns/Description_IndexType, but that's a bit much in the existing databases I administer.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Steve Jones - SSC Editor SSC Guru Points: 736063 More actions · Answer 13

I still think it's a fundamental bad idea to include periods.

It will also distract and confuse others, which is something you should consider. The job is bigger than you and it shouldn't be a mess for the next guy/gal.

I'd still use OrderDetailOrderIDOrderDetailID

It's hard to read, but you don't do it that often. And when you do, you get used to it quickly, it's quick and fits with other naming conventiopns, etc.