September 3, 2013 at 5:32 am
Hello all
I have recently been tasked with putting a naming convention in place for a new Sql Server Database/Project. I haven't set any naming conventions in a while as more recently I have found myself in environments where there is one in place.
I guess for naming conventions I don't have any strong preferences the one way or the other, other than for it to be consistent and easy to type. Is that wrong or right... can't say.
I wondered what others were using and if there any reasons why you would use the one convention over another?
September 3, 2013 at 5:47 am
I've seen a lot of religious discussions about naming conventions. My advice would be to search this site and others and weigh up the pros and cons of each individual decision (eg CamelCaseObjectNames v underscore_object_names, whether to use Hungarian notation, and so on). You can pick and choose what suits you best and implement that.
John
September 3, 2013 at 6:11 am
I don't know how many developers you're going to have working on this database, but please know ahead of time that you're not going to be able to make everyone happy. Some people are very passionate about their naming conventions and don't want to change anything...ever.
IMO, the most basic one is "Thou shalt not have spaces in thy field names". I know it's allowed, but that's personal preference, maybe because I came over from the Oracle world years ago.
Whatever you do, keep in mind that it'll be a living document and will probably be revised more than a couple times.
September 3, 2013 at 6:57 am
Thanks for the responses.
September 3, 2013 at 2:00 pm
Whatever rules you decide on, you should enforce them programmatically. Otherwise, the rules will be broken and be meaningless.
Also, follow the first rule of naming -- don't build meaning into the name (at least for non-internal-only objects).
For example, don't name tables with "tbl_", "tb_"; views with "vw_", "_vw"; procs with "sp_", "proc_", "_sp", "up_"; etc.. Tables can change to views, and vice versa; so don't create a name that will become a "lie" later.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
September 4, 2013 at 6:34 am
ScottPletcher (9/3/2013)
Whatever rules you decide on, you should enforce them programmatically. Otherwise, the rules will be broken and be meaningless.Also, follow the first rule of naming -- don't build meaning into the name (at least for non-internal-only objects).
For example, don't name tables with "tbl_", "tb_"; views with "vw_", "_vw"; procs with "sp_", "proc_", "_sp", "up_"; etc.. Tables can change to views, and vice versa; so don't create a name that will become a "lie" later.
Scott, I couldn't agree more with you. It drives me nuts when people name things like this. Naming all the procedures with a prefix of "sp_" only helps to meld everything together when you browse it in SSMS. My personal favorite is when you have an inline function that changes to a (not inline) table-value function. :w00t: Of course, once a system is in place, it's ridiculous to change it because of all the different calls to it by multiple people and applications.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply