<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
Programming
»
General
»
Naming Conventions Standards
24 posts, Page 1 of 3
1
2
3
»
»»
Naming Conventions Standards
Rate Topic
Display Mode
Topic Options
Author
Message
Rofty
Rofty
Posted Tuesday, July 07, 2009 1:44 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, April 25, 2012 10:24 PM
Points: 192,
Visits: 229
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 procdure 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?
Arguing with Programmers are like wrestling a pig in mud, soon you realize the pig is enjoying it.
Post #748345
Jack Corbett
Jack Corbett
Posted Tuesday, July 07, 2009 8:26 AM
SSChampion
Group: General Forum Members
Last Login: 2 days ago @ 12:22 PM
Points: 10,571,
Visits: 11,871
I don't use prefixes on tables and stored procedures. I do tend to use prefixes on views (vw) and functions (fn) to differentiate them from tables and stored procedures. You'll get as many opinions on this as there are people in the forums. In my opinion the important thing is that the organization have a standard and stick to it.
Jack Corbett
Applications Developer
Don't let the good be the enemy of the best. --
Paul Fleming
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #748588
Jeff Moden
Jeff Moden
Posted Tuesday, July 07, 2009 9:28 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 32,893,
Visits: 26,770
I don't use any prefexies in my production databases. The reason is that a table could be changed to a view or vice versa and having a prefix would just complicate things. Add synonyms in on top of that.
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #748657
GSquared
GSquared
Posted Tuesday, July 07, 2009 9:36 AM
SSCoach
Group: General Forum Members
Last Login: Monday, May 06, 2013 1:09 PM
Points: 15,439,
Visits: 9,569
I don't use prefixes by choice. Current employer requires them, so I'm using them, but I dislike it.
I don't find that it adds anything useful. It's not like I can't easily find out what object type something in a From clause is.
I do find that it creates problems. As Jeff mentioned, what if you want to change from a table to a view? If you name the view the same as the old table, you don't have to change any code that accesses it. If you have to rename it, to change a "tbl" prefix to "vw", then you have to change every piece of code that accesses it. That doesn't really apply to UDFs, because you have to at least have parentheses after them, which you wouldn't have on tables/views, but at the same time, the parentheses also eliminate any value from having a "udf" or "fn" prefix on it, since you can visually determine object-type by that.
So, I don't see a benefit to it, and do see drawbacks.
However, I don't consider it important enough to fight over. Go with what you're comfortable with. Set a standard and stick to it. That's more important than the specifics of the standard, in this case.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #748664
steveb.
steveb.
Posted Tuesday, July 07, 2009 10:59 AM
SSCrazy
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 7:42 AM
Points: 2,802,
Visits: 7,103
I do not use prefixes for object names for the reasons stated above, also I use SQL prompt and I find that the use of prefixes does not work well with the auto-completion of names as every table will have the same few starting characters, and this also annoys our developers as the Intellisense in VS.Net has the same issues..
Post #748730
Rofty
Rofty
Posted Wednesday, July 08, 2009 8:31 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, April 25, 2012 10:24 PM
Points: 192,
Visits: 229
Hey Guys
So far the overall decision is to use Hungarian Prefixes. Even though i realize the risks involved, the decision is based on understandable reasons:
- Large development team with different expertise level members will be working on the database and needs to distinguish between different object.
- Most find it more readable and different object stand out from queries.
- Chances of Tables->Views conversation are extremely low.
Thanks for your advice though.
Arguing with Programmers are like wrestling a pig in mud, soon you realize the pig is enjoying it.
Post #749299
GSquared
GSquared
Posted Wednesday, July 08, 2009 8:34 AM
SSCoach
Group: General Forum Members
Last Login: Monday, May 06, 2013 1:09 PM
Points: 15,439,
Visits: 9,569
Like I said, pick a standard and stick to it. In this case, that matters more than what the specifics of the standard are. The advantages/disadvantages to each are minor.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #749310
Rofty
Rofty
Posted Wednesday, July 08, 2009 8:42 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Wednesday, April 25, 2012 10:24 PM
Points: 192,
Visits: 229
Thanks GSquared
I found with previous projects that if you a strict standard that you stick with it makes the occasional adjustments so much easier.
Arguing with Programmers are like wrestling a pig in mud, soon you realize the pig is enjoying it.
Post #749326
Jeff Moden
Jeff Moden
Posted Wednesday, July 08, 2009 2:42 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 32,893,
Visits: 26,770
roelofsleroux (7/8/2009)
- Most find it more readable and different object stand out from queries.
I'm sure you can produce a white paper on the multitude of opinion polls that substantiates that statement, right?
And for large development teams having a plethora of skill levels, they should have no reason to know the difference between a table and view. If they don't know how to find out if it's a table or a view, perhaps they shouldn't actually be writing SQL.
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #749611
Jeff Moden
Jeff Moden
Posted Wednesday, July 08, 2009 2:46 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 32,893,
Visits: 26,770
GSquared (7/8/2009)
Like I said, pick a standard and stick to it. In this case, that matters more than what the specifics of the standard are. The advantages/disadvantages to each are minor.
BWAA-HAA!!! You left out a word....
Like I said, pick an intelligent standard and stick to it.
Hungarian notation in SQL server just doesn't fit that bill for me especially since all tables, regardless of how they are named, all fall under the table icon in the object browser.
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #749612
« Prev Topic
|
Next Topic »
24 posts, Page 1 of 3
1
2
3
»
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
