February 29, 2008 at 7:21 am
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!;)
February 29, 2008 at 8:20 am
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! 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
February 29, 2008 at 10:24 am
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.
February 29, 2008 at 10:19 pm
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
October 12, 2012 at 10:29 am
Viewing 5 posts - 31 through 34 (of 34 total)
You must be logged in to reply to this topic. Login to reply