Grant Fritchey (4/6/2005)
Naming standards are very good things. Common abbreviations are very good things.
Very good things can, however,be taken to silly extremes. We've got a logical modeling team tasked with, along with maintaining an enterprise logical model, establishing naming conventions. Unfortunately, these people work in the ethereal world of logical modeling, exclusively. They don't have to write code against the models they create, so naming every single table in a database Policy...* is not a problem for them even when we're talking about a couple of hundred tables, all inside a database named Policy. Establishing incomprehensible abbreviations like 'ddltbl' for deductible (do abbreviations generally add letters? note the new 'l') doesn't seem to slow down their work at all. The rest of us, dba's and developers,have been driven insane trying to get them to use an abbreviation like 'org' for organization instead of 'orgntzn'. I have, on more than one occasion, brought a dictionary over to their desk and pointed at common abbreviations defined with along with a word to no avail.
Don't get me wrong. I am in favor of practing a common approach. Just make sure the common approach makes sense.
Oh, and underscores in object names suck.
Man, do I ever agree with that!
Even though this article is 3 years old, lemme add a couple of things...
This is NOT Oracle... we DON'T have the limit of 30 characters for object names! While it's good to have a published and available list of abbreviations, abbreviating words like Account or Number or Service just aren't necessary. For example, how many different abbreviations have you seen for "Number"? Num, Numb, Nbr, Nmbr... What's that do for you? Save 2 or 3 characters only to have to be maintained on some standard abbrevieation list? Spell the bloody thing out... let aliases and good formatting take care of the rest.
I also agree about underscores... people want abbreviations to save space and then they use underscores! If you think about it, it actually takes less time to type Mixed Case than it does underscores, unlike Oracle, the casing is preserved, and it's just as or maybe more readable than the underscores.
I also agree about what was said about designers... yes, they need prefixes such as "Policy" or "Order" or whatever because they don't really have a good way to identify the schema or the database that something may be in... but don't name your tables that way... what if they need to be moved?
Views? I used to thing is was good to preface views with a "v" just to make it easier for developers to find... but it's really not a good idea... We started one thing out as a table... then, we decided to change it to a view... after a bit, we decided it should be two tables and the view would be repointed to the most current... then, we decided it should be a synonym, instead. If we had prefaced the name with "v" or worse yet, "tbl", we would have had to change a bunch of interface, stored procedure, function, Hibernate Mappings, and some (ack!) embedded GUI code and then would have had to retest all that stuff just to make sure we didn't screw something up. Instead, all we had to do was make sure that each "change" returned the same result set as an "object" and that was all.
So far as the article goes... ummm... sure... the title was a wee bit misleading. And, is the subject a rehash of something that almost everyone knows? Ummm... sure... BUT, just like many other articles, including many of my own, points are covered and there are a surprising number of folks (most are forum "lurkers") that just don't know these things. It's good to see articles that remind old dogs of the basics and newbies of stuff they may have never known otherwise. As always, there's a ton of additional information to be found in the discussions for each article.
Last but not least, I would find it very difficult to write an article about formatting and naming conventions... these are very nearly religious subjects that many individuals either take a great amount of pride in or are religious about writing their code as fast as they can without regard to any format or convention. If such things are to be followed, they must be both well published and they must be enforced. Remember that enforcement requires code reviews and it shouldn't be just the DBA that does code reviews... the DBA should be the final check only and the easier folks make the readability of the code, the better the DBA is going to treat you and the easier it will be to troubleshoot the code in the future.