dhamilton-905368 (1/25/2010)
I do believe that most DATABASES (something most people don't do!) should be prefixed with a "db"
Why?
most tables should be prefixed with a "tbl"
Why?
and most stored procedures (which I won't personally do db CRUD without) should be prefixed with "sp".
Why?
If there's a piece of SQL script that reads
USE Travel
EXEC dbo.ScheduleTravel
is there any doubt whatsoever that Travel is a database and ScheduleTravel is a stored procedure?
Can you USE a view or EXEC a database?
All I find that prefixing stored procedures does is make it harder to locate them and navigate to them in Object Explorer
Tables and views are worse. Let's say I have a large table that's been called tblClientTransactions, then, due to volume or new development it becomes necessary to split the table into 2. The standard trick would be to create a view with instead of triggers with the name of the table to present an unchanged interface to any queries that need to see the table as it was (especially if the queries are embedded in the client app). Now I have a view named tblClientTransactions. Hmmmm....
The only thing that I use prefixes on are indexes, primary keys and unique constraints. Why? Well, two reasons. They never appear in code (or at least shouldn't) and so the more complex name is not a burden anywhere. So I can see, when looking at a query's execution plan whether the index used is just an index or if it's one of the constraints as the only thing that the exec plan tells me is whether or not the index is clustered
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability