Coding standards are great but seems you always have someone who just plain ignores them. Which is a shame.

As for DTS I suggest you make a name that will organize properly but a convention is not really a true neccessity here as you can include a package description. However the name should be a logical short version of the description or make a certain sense in helping quickly ID it. I usually use DBRelatedTO_ShortDescrip such as

PUBS_ExportAuthToXlsOnWeb

"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

Not bad! We don't have one much of one here. While senior people may rebel a bit, junior developers LIKE having a standard to follow. Not only that, they tend to survive by cloning code frequently, so if you have a a bunch of different styles in use already, it just gets worse!

One thing I'd add, no spaces in database names either. If MS would PLEASE add a server configuration setting that will let disallow spaces in object names totally, that would SO useful.

Great article. I was wondering how far out I would be with my naming conventions, but fortunately, I use pretty much all of those. Only ones I had not thought of was Triggers and Defaults!

With regards to DTS, I do try and adhere to a standard. All DTS Package names should give an indication as to the task. For example: JDE Inventory Download. For the description field I use the Database Name. Just found it easier that I could group the DTS's to see which data goes in which DB. As with all objects within the DTS, I always change their default description. For example, if I inserted an "Execute SQL Task", I'd change alter the Description to make it more meaningfull. But again, all that is documented!

One other standard which I just started to make my SP's meaningfull. I use <Application>_<SQL Statement>_<SP Name>. For example: SHOPFLOOR_INSERT_NEWORDER

And very much agree with Antares. Standards are great...however, trying to make others accept and adhere to your standards is another issue..!!

Nice Article. Our standards are similar but we include a further descriptive prefix to tables, views and procedures to enhance readablility in any consolidated documentation for projects.These include a single letter identifiying the object type ( 't' for tables, 'v' for views, 'p' for procs) and a single letter for basic function ( 'l' for lookup, 's' for static, 't' for transaction, 'p' for procedural ).

Good article. (Was that an echo?) It is always worth reading up on how other people do, let's call it "non-standardized" things, such as naming and coding conventions. Eventually, they become widespread standards, or so one can only hope.

A quick thought or two: for indexes and the like, instead of tagging them with a number we put the column actually indexed at the end (such as PK_Table_ColumnName). For compound indexes, either we do multiple columns, a brief description, or (if too long) an arbitrary number (1, 2, etc.) All this makes it easier to get a list of indexes for a table and see what's covered and what's not.

Steve, just from idle curiosity, and with no intent to provoke lengthy debate on points of religious dogma, are there an particular reasons why do you avoid underscores and all-upper case words? We mix and match in what I like to think of as a judicious fashion. When reading code or reports, quick visual identification of disparate objects can be very useful.

I do agree that quick identification can be usefu. One reason why I put the tablename first is so all items relating to the table are close together.

As far as underscores go. No real reason other than I had to pick something and tend to prefer UsingProperCaseNames to Using_Proper_Case_Names. Shorter, plus this is what MS decided to recommend for the .NET stuff. I always disliked the all CAPS stuff in C for constants. I know they stand out, but I've never had an issue running through code and checking variables. If I'm confused or new, I should be extra careful anyway before changing the code. Plus it's easier for me to just be consistent than to try and figure out if I should be making something all CAPS.

Not against it and if I worked in your shop, I'd adapt. Just what I decided was easier.