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


Database and its Objects Naming Standards


Database and its Objects Naming Standards

Author
Message
Scott Arendt
Scott Arendt
SSCarpal Tunnel
SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)SSCarpal Tunnel (4.7K reputation)

Group: General Forum Members
Points: 4691 Visits: 1723
I will agree that it is a personal preference and completely meaningless unless enforced.

Also, my personal preference is No_Underscores!!
Eirikur Eiriksson
Eirikur Eiriksson
SSC-Forever
SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)

Group: General Forum Members
Points: 40553 Visits: 19471
Scott Arendt (4/25/2014)
I will agree that it is a personal preference and completely meaningless unless enforced.

Also, my personal preference is No_Underscores!!

Do not want to underscore any preferences but I find object_subject_action conversation very useful
Cool
andrew gothard
andrew gothard
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2764 Visits: 5969
Oh, and one other thing.
Anything justified purely on the basis of "It Saves Typing" is grounds for the removal of their keyboard, possibly bodyparts depending on how bad the witlessness being justified in this manner is - and a phone call to HR. Possibly an undertaker.

I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
OCTom
OCTom
SSCarpal Tunnel
SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)

Group: General Forum Members
Points: 4133 Visits: 4152
The very worst naming convention I saw was years ago on an AS400 (1981).

Tables are called files on that machine and reside in a library.

The naming was such:

Library001
File001
Field001
Field002
Field003

File002
Field001
Field002
...

Library002
File001
... etc ...

Their program names were Pgm001, Pgm002, etc.

It was awful to work with. It was a major ERP system. One of the biggest at the time.

So, whatever you choose for naming convention, make sure they're clear, consistent, and enforced.

Tom
andrew gothard
andrew gothard
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2764 Visits: 5969
OCTom (4/25/2014)
The very worst naming convention I saw was years ago on an AS400 (1981).

Tables are called files on that machine and reside in a library.

The naming was such:

Library001
File001
Field001
Field002
Field003

File002
Field001
Field002
...

Library002
File001
... etc ...

Their program names were Pgm001, Pgm002, etc.

It was awful to work with. It was a major ERP system. One of the biggest at the time.

So, whatever you choose for naming convention, make sure they're clear, consistent, and enforced.

Tom



Saves Typing

I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Jeremy Brown
Jeremy Brown
SSC Eights!
SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)

Group: General Forum Members
Points: 827 Visits: 313
I find more often than not, people go overboard on naming standards (in my honest and humble opinion).

I know I'm probably going to catch a lot of flames for this, but, naming standards that include things like the object type seem senseless to me. Each object in SQL Server has relevant metadata that accurately describes what the object type is (among other things).

I'm more a fan of the simple rule that code should be self-describing. In other words, entity names should accurately represent what entity is being maintained. Executable code should describe the function or behavior performed (more or less).

The "naming standard" should establish the common language usage for these things. For example, functional code that "gets" things from the database should begin with "get". In other words, its an agreement between the developers that we use these common words to describe the action performed. Likewise anything that commits something should be "put" or "write". Choose whatever verbs you like, but make is sensible.

In other words, make it lightweight. Easy enough that can be generate -able in code, but not so difficult that it takes a maintenance programmer a degree in quantum physics to be able to understand.



Sean Lange
Sean Lange
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: General Forum Members
Points: 62509 Visits: 17959
Jeremy Brown (4/30/2014)
I find more often than not, people go overboard on naming standards (in my honest and humble opinion).

I know I'm probably going to catch a lot of flames for this, but, naming standards that include things like the object type seem senseless to me. Each object in SQL Server has relevant metadata that accurately describes what the object type is (among other things).

I'm more a fan of the simple rule that code should be self-describing. In other words, entity names should accurately represent what entity is being maintained. Executable code should describe the function or behavior performed (more or less).

The "naming standard" should establish the common language usage for these things. For example, functional code that "gets" things from the database should begin with "get". In other words, its an agreement between the developers that we use these common words to describe the action performed. Likewise anything that commits something should be "put" or "write". Choose whatever verbs you like, but make is sensible.

In other words, make it lightweight. Easy enough that can be generate -able in code, but not so difficult that it takes a maintenance programmer a degree in quantum physics to be able to understand.


I agree that the naming standards can go insanely overboard. However your comment about starting the name with the verb is one I disagree with immensely. When you have a system with even a few hundred stored procs it is a PITA when they are all grouped by what they do instead of by what they deal with. It is difficult to find a given stored proc for "get" when there are 200+ that all begin with "get". This is why starting with the object name is helpful. The list is now sorted by object instead of function making it much easier to find the 10-12 procs all dealing with Orders. ;-)

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Jeremy Brown
Jeremy Brown
SSC Eights!
SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)SSC Eights! (827 reputation)

Group: General Forum Members
Points: 827 Visits: 313

I agree that the naming standards can go insanely overboard. However your comment about starting the name with the verb is one I disagree with immensely. When you have a system with even a few hundred stored procs it is a PITA when they are all grouped by what they do instead of by what they deal with. It is difficult to find a given stored proc for "get" when there are 200+ that all begin with "get". This is why starting with the object name is helpful. The list is now sorted by object instead of function making it much easier to find the 10-12 procs all dealing with Orders. ;-)


See? It didn't take very long to get a response Smile.

I understand what you're saying. Honestly I don't feel as strongly one way or another. Fine, you want the object name first, go for it. You want the behavior first, fine by me. Its all a matter of perspective.

If you're using SSDT (and you should be) to develop your database, you can quickly view object dependencies for any entity. When you can do that, it starts to be "not such a big deal" frankly, what the name of the object really is. You are able to make changes to that object and / or make changes to any dependent objects pretty quickly - and validation checks make sure it doesn't break any other dependent code.

The only gotcha is in "generated" code - dynamic SQL for example. Dynamic SQL tends to be table driven in many cases, so for those cases you have to maintain custom metadata - and in that case I can go along with your method.

In other words, it may have been a huge deal if most of your SQL development were being done in the legacy method of using management studio connected to a development server. Yeah I can see your point there - it is a pain in the butt.



Sean Lange
Sean Lange
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: General Forum Members
Points: 62509 Visits: 17959
Jeremy Brown (4/30/2014)

Honestly I don't feel as strongly one way or another. Fine, you want the object name first, go for it. You want the behavior first, fine by me. Its all a matter of perspective.


That is the basic sentiment of this entire thread. Everybody, and every shop, has their own opinion. We all agree that no matter what you choose the MOST important thing is to be consistent. Most of us can, have and will work with established conventions as long as they are consistent.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Eirikur Eiriksson
Eirikur Eiriksson
SSC-Forever
SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)

Group: General Forum Members
Points: 40553 Visits: 19471
Sean Lange (4/30/2014)
Jeremy Brown (4/30/2014)

Honestly I don't feel as strongly one way or another. Fine, you want the object name first, go for it. You want the behavior first, fine by me. Its all a matter of perspective.


That is the basic sentiment of this entire thread. Everybody, and every shop, has their own opinion. We all agree that no matter what you choose the MOST important thing is to be consistent. Most of us can, have and will work with established conventions as long as they are consistent.

IMHO and as Sean said, it is about serving the purpose and being consistent. What ever standard is used, stick to it. Do not change half way through and plan for the target size and complexity of the system. Often names such as get_me_this,_that or _the_other are fine but sometimes they are not. And of course, this should be applied to [datacentre].[cluster].[server instance].[database].[schema].[whatever...]
Cool
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search