Object Naming Standards 2

[JohnBates]

hi everyone,

Does the DBA establish the object naming conventions at your office?

I will be working with the Mgr of Programming to set some naming guidelines for our 2005 database objects.

I'm leaning towards:
'vw'...
'tbl'....
'proc'....
and 'ufn'....

Has your naming standard/prefix changed with 2005 or are you still using what was in place for 2000?

Thanks, John

 

[mrdenny]

Not to sound snooty but; Why pray tell are you using hungarian notation for the objects? Hungarian notation has been out of favor for a while. If it's a table why put tbl in front of the table name? You know that it's a table. The same goes for the rest of the objects.

If you have the object name and need to know what kind of object it is, then the object name probably isn't descriptive enough.

For tables the name is simply what the table holds. The same goes with views. Procedures are prefixed with sel, ins, upd, del, util, etc. Then the rest of the procedure name is what the procedure does, descriptive without being crazily long.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog

 

[JohnBates]

If it's a table why put tbl in front of the table name?"

Amen, mrdenny. And that has been my practice for years, to not use any prefix for tables.

However, I'm now in a setting where the vast majority of the software is purchased packages - Lawson Financials, Ramco etc. Their views end with _vw.

The purchased systems objects use a schema of 'dbo'.

I'm thinking of creating a new schema 'pncl' our co. abbreviation, and having developers use pncl as the schema for any user-created objects. I want to be able to identify objects that are not part of the base install. That's really what prompted my questions.

Do you think using a new schema for our objects is the way to go ?

Thanks, John

 

[mrdenny]

A schema is definitely a good way to go. I use them (other than dbo) quite often when setting up objects in databases for one reason or another. Using them to denote an in-house object from a vendor object is an excellent use of them.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

My Blog

 

[juliane26]

John,
we are setting up a new SQL 2005 environment over here to centralize SQL applications.

We have for all other database system naming conventions: the strictest on the host, followed by Unix systems.

In SQL server I can forget about naming conventions going down to table names or views.

The simple reason is that one third or more of the applications is packaged software.
The second third - if not more - are access applications having moved to sql server to be multi-user capable. They have usually few tables all being called dbo.tabnamex.

There are few applications left being developed with .Net using proper development process. When they have a proper design phase, they usually have sensible names too.

I started with naming conventions for instances, databases and jobs - all those things really getting a little confusing with the time - to be able to manage properly.

SCHEMA: I sure ask for using schemas !!
Why? I really have an application using 15 databases all having only the dbo schema with about 6 tables. And this was packaged software! No you don't want that ...
It is hard to be enforced ('We always used dbo') but sensible anyway. A way to group objects - many use cases like clients or temporary objects or whatever.




Juliane