Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase «««1234

Practical Methods: Naming Conventions Expand / Collapse
Posted Friday, February 29, 2008 7:21 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, August 10, 2011 12:13 PM
Points: 307, Visits: 565
Although this topic is almost a year old (at this writing), I'll throw in one of my pet peeves...

Don't abbreviate anything by omitting one or two letters.

Emplyee for Employee
Addrss for Address
Managmnt for Management
EmplyeeAddrss for EmployeeAddress

This serves no purpose because eliminating 1 or 2 letters isn't shortening it enough to make any difference, and these are not common abbreviations. Plus, most people will always type those names out in a query wrong (we tend to read over the missing letters and subconsciously fill them in), so writing stored procs and queries against these object names is a pain because you spend more time going back to check "what was that name again?" each time you get an 'invalid object' error.

Abbreviations are helpful if you have a lot of objects that contain the same word. For example...Management. A nice long word that could be used in a bunch of object names. ManagementObjective, ManagementHierarchy...which makes the names even longer. In this case, how about a well-accepted abbreviation for Management, such as 'Mgt' or 'Mgmt' (but be consistent, don't use both), so your objects become MgtObjective, MgtHierarchy. This works really well when you have several objects pertaining to Management, it makes it easier to read the names, and they all group together in an alpha-ordered list.

Just use a little common sense...just a little. :)

If it was easy, everybody would be doing it!;)
Post #462347
Posted Friday, February 29, 2008 8:20 AM



Group: General Forum Members
Last Login: Yesterday @ 7:19 PM
Points: 42,047, Visits: 39,434
So, the young couple took the new born twins, a boy and a girl, to the God Father. "God Father", said the young Mother... "We would be honored if you named our children".

The God Father thought for a minute and said "We'll call the girl 'Denise'." "Oh!", said the young Mother. "What a beautiful name for a girl. What shall we call the boy?"

The God Father thought for a minute more, then cracked a smile from ear to ear, and raising his hand with index finger pointed as if having a revelation, proudly announced...






Be careful when choosing a naming convention... it may be something that you have to live with! :D

--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."

Helpful Links:
How to post code problems
How to post performance problems
Post #462401
Posted Friday, February 29, 2008 10:24 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, March 3, 2008 7:33 AM
Points: 2, Visits: 5
I strongly agree here. Use plain English whenever possible and most items should be immediately apparent even to new users/programmers. Lowercase "t" and "v" are pointless when you consider that the SQL Server management tools instantly show what is what, not to mention the fact that if you are working on a database in any way you should already be aware of it's contents. Some exceptions have to be made to avoid reserved words, but this does not rise to level of needing to prefix everything.
Post #462562
Posted Friday, February 29, 2008 10:19 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, October 26, 2016 2:46 PM
Points: 221, Visits: 498
I agree with spelling things out but couldn't disagree more with prefixes. Love schema's for grouping Sales.Orders, Sales.OrderItem. For the folks that love a tName or vName let me ask on thing? Do you apply the same thing to your columns? After all these are types of objects as well. I worked on systems that contained very elaborate prefixes. There is a wbocspuCompany for web based object Company stored procedure update and yes there was an i (insert), d (delete), s (select). The vendor carried this into the column names as well. It is a huge pain in the a$$.

It's handy to be able distinguish between tables and views in code but I found it most useful to apply an _v at the end of the name. This gives me Customer table (nice, clean, simple) and related views Customer_v and Customer_vTop100 and Customer_vFormer.

Applying an action at the end of stored procedure names allows the sprocs based on a single object to be grouped together. I'll have Customer_del, Customer_get, Customer_upd, Customer_ins, (or Customer_sav for insert/update). If I use a prefix then I have all my del[ete] procedures together, etc. I guess that may be handy if I'm trying to modify all my delete procedures. But normally I'm making a change to a Customer table and want to change all of the code related to those items. Give me a moderate size database with 100 tables and each Customer object will have

I'll bet after reading this post you were able to figure out what the objects above do. After 15+ years of dealing with both prefixes or suffixes -- IMHO, suffixes and Object_Action names are the only way to go.

Remember, it's an opinion and it may be worth exactly what you paid for it.

--Paul Hunter
Post #462778
Posted Friday, October 12, 2012 10:29 AM

Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, December 4, 2015 12:28 PM
Points: 54, Visits: 471
archived link.
Post #1372271
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse