Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234»»

Database and its Objects Naming Standards Expand / Collapse
Author
Message
Posted Friday, April 25, 2014 6:38 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 7:13 AM
Points: 3,488, Visits: 1,498
I will agree that it is a personal preference and completely meaningless unless enforced.

Also, my personal preference is No_Underscores!!
Post #1565057
Posted Friday, April 25, 2014 11:08 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 7:34 AM
Points: 1,975, Visits: 5,140
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
Post #1565186
Posted Friday, April 25, 2014 2:11 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 6:29 AM
Points: 346, Visits: 3,351
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.
Post #1565245
Posted Friday, April 25, 2014 3:00 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 7:26 AM
Points: 2,582, Visits: 3,836
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

Post #1565247
Posted Saturday, April 26, 2014 3:50 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 6:29 AM
Points: 346, Visits: 3,351
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.
Post #1565373
Posted Wednesday, April 30, 2014 9:20 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, May 4, 2014 10:21 PM
Points: 202, Visits: 307
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.



Post #1566457
Posted Wednesday, April 30, 2014 9:27 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 7:44 AM
Points: 13,462, Visits: 12,320
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 Moden's 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)
Post #1566459
Posted Wednesday, April 30, 2014 9:39 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, May 4, 2014 10:21 PM
Points: 202, Visits: 307

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 :).

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.



Post #1566465
Posted Wednesday, April 30, 2014 9:47 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 7:44 AM
Points: 13,462, Visits: 12,320
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 Moden's 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)
Post #1566470
Posted Wednesday, April 30, 2014 9:53 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 7:34 AM
Points: 1,975, Visits: 5,140
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...]
Post #1566475
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse