July 7, 2009 at 7:50 am
There are a lot of opinions regarding standards or general preference on the subject of database object naming conventions.
I'm used to a environment where object have prefixes like tbl, vw, sp and fn.
tblEmployee
vwGetActiveEmployee
spStoreEmployee
fnGetEmployeeList
Although i read that that a sp_ prefrix can result in a performance penalty seeing as SQL server uses this in the Master Database as a standard prefix for Stored Procedures. This means that when you want to use your own stored procedure with such a prefix, SQL will try and locate it in the Master Database first and then try your database. Producing a performance slack.
My question:
Are there a standard or would it be wrong to use prefixes?
[font="Courier New"]-----------------------------------------------------------------------------------------------------------------------
😀 Arguing with Programmers are like wrestling a pig in mud, soon you realize the pig is enjoying it. 😀
-----------------------------------------------------------------------------------------------------------------------[/font]
July 7, 2009 at 8:26 am
First, the sp_ issue is a problem, and you could avoid it. spXXX is fine.
Many people choose a standard for procedures (usp, USP_, sp), but I rarely see tables prefixed. Views often have "vw" or "v" before them.
A standard can help organize (put them all together in the object browser), though now with the various folders, it's easy to see what is where. I think the best place for having a standard is really for views and functions. For views, this allows you to be aware that there are multiple tables underneath the view, and that could impact performance. It's a trigger for me to watch what I'm querying. Or to pay more attention to tuning here.
Same for functions. Since they can impact performance at times when used inline, I use an "fn" prefix that lets me know I wrote this (or someone else did) and to be careful.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply