Object naming
-
Just when you think you know what's right....
New blood in my team is challenging our accepted wisdom on SQL object naming. We use tbl, usp, vw and fn as prefixes for the names of our objects in SQL. Comes as second nature because we're all programmers too, and so always use prefixes on variables as well. I'm very keen on this, and also hate mis-use of reserved words, abbreviation and various other things I've learned the hard way in the last 14 years or so.
Tables are always named in the plural and all names are properly descriptive (eg stored procs have verbs in the name).
Our new, young, .Net/OO/UML whizzy people are suggesting dropping some or all of the object prefixes for new development. They point out that you can almost always work out what something is from how it is referenced (eg a From clause will always be referencing a table or a view). I don't want to be a dinosaur, but I also don't want to lose standards that we have worked hard to keep.
What does the rest of the world do / think?
Bill.
-
This appears to be a purely academic debate. Standards are established within an organization to maintain some type of order. There is no reason that standards can not change or new ones added given careful thought. But the argument that one can tell what an object is by its call is pure nonsense. While true the problem remains that one must have access to the calling process in order to determine the type of object. (With out referencing the sysobjects table.) What if there is a personnel turn over or the code is locked down or otherwise access restricted. Why make someone’s job harder.
My suggestion is to stick to your guns but be a little flexible. Most shops I have worked in have had a naming convention much like you have identified.
Good Luck
-
Standard to ease your work. by maintaining it, no one can drag you to their own standards. In addtions, Standard are always within your organzation. there is no global set of rules for standards!
My Blog:
http://dineshasanka.spaces.live.com/ -
well - this article addresses only stored procedures naming conventions but the posts in response should give you a good indication of where different people draw the line between "acceptable" & "beyond acceptable"!
**ASCII stupid question, get a stupid ANSI !!!** -
I for one can not understand why people want to differentiate between tables and views using prefixes. They are not different! For instance, consider this common scenario:
You have a table FOOBAR (a, b, c). There are lots of applications using SELECT a, b, c FROM FOOBAR. Sometime later you need to split FOOBAR into FOO and BAR. You would now get FOO (a, b) and BAR (a, c). To avoid having to modify all applications you can simply add a view FOOBAR that joins FOO and BAR to return the (a, b, c) set as the old table did. The applications have no idea that there is now really two tables.
If FOOBAR would be called tblFOOBAR you would now have a view prefixed with tbl, or you would need to modify your apps.
Prefixes are a thing of the past, a mistake caused by lack of support from tools and unclear thinking.
-
Hungarian Notation was invented because C had no type safety, so programmers had to keep track of data types themselves.
I personally think it is unnecessary and ugly, it isn't so hard to figure out what data type something is what with modern IDEs (or the INFORMATION_SCHEMA in SQL). And sometimes it doesn't matter which type something is (as in Chris Hedgate's example). And sometimes you change a data type and have to either replace hundreds or thousands of references to that variable (or whatever it is), or have the wrong notation prefix everywhere.
But, different strokes for different folks... If I start on a pre-existing project (or work with a pre-existing group) I follow whatever convention is already in use. It isn't all THAT important.
-- Stephen Cook
-
Hungarian Notation was invented because C had no type safety, so programmers had to keep track of data types themselves.
Actually, Hungarian Notation as it is known was 'invented' by a documentation writer that did not understand what the inventor really meant. See Joel Spolsky's Making Wrong Code Look Wrong for more info. Scroll way down towards the end if you do not wish to read the entire article. It is very good though so I highly recommend it.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply