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


Practical Methods: Naming Conventions


Practical Methods: Naming Conventions

Author
Message
TraderSam
TraderSam
Say Hey Kid
Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)

Group: General Forum Members
Points: 691 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. Smile

If it was easy, everybody would be doing it!Wink
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (214K reputation)SSC Guru (214K reputation)SSC Guru (214K reputation)SSC Guru (214K reputation)SSC Guru (214K reputation)SSC Guru (214K reputation)SSC Guru (214K reputation)SSC Guru (214K reputation)

Group: General Forum Members
Points: 214278 Visits: 41979
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...

...

...

...

...

"DeNephew!"

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

--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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
DBDeveloper
DBDeveloper
Forum Newbie
Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)Forum Newbie (6 reputation)

Group: General Forum Members
Points: 6 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.
SQLNightOwl
SQLNightOwl
SSChasing Mays
SSChasing Mays (612 reputation)SSChasing Mays (612 reputation)SSChasing Mays (612 reputation)SSChasing Mays (612 reputation)SSChasing Mays (612 reputation)SSChasing Mays (612 reputation)SSChasing Mays (612 reputation)SSChasing Mays (612 reputation)

Group: General Forum Members
Points: 612 Visits: 523
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
Todd M. Owens
Todd M. Owens
SSC-Enthusiastic
SSC-Enthusiastic (108 reputation)SSC-Enthusiastic (108 reputation)SSC-Enthusiastic (108 reputation)SSC-Enthusiastic (108 reputation)SSC-Enthusiastic (108 reputation)SSC-Enthusiastic (108 reputation)SSC-Enthusiastic (108 reputation)SSC-Enthusiastic (108 reputation)

Group: General Forum Members
Points: 108 Visits: 471
archived link.
http://web.archive.org/web/20050723022626/http://www.dbazine.com/db2/db2-disarticles/gulutzan5
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