|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Stored Procedure Naming (Beginning with SP)Hi folks. I know the official recommendation is to not begin stored
procedure names with "sp". But, is that case sensitive? Is it ok to start them with "SP" in caps? Pat ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- Why to take that risk?
Should I Use the sp_ Prefix for Procedure Names? http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=23011&DisplayTab=Article AMB Show quote "Pat" wrote: > Hi folks. I know the official recommendation is to not begin stored > procedure names with "sp". But, is that case sensitive? Is it ok to start > them with "SP" in caps? > > Pat > > > > ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- > http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups > ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- > sp stands for "System Procedure", not "Stored Procedure", and this prefix
(actually "sp_") is specifically recognized by SQL Server, and, allows a stored Proc with this prefix, located in teh master database, ti be accessible from any other database on the server... Whether the Character Collation (Case Sensitive or not) of your server would affect whther SP_ is also subject to this functional distinction, or not, There is not reason to use either prefix for your stored procs... Sql Objects should not be named with "Object-Type" identification prefixes, like MS Access objects or OOP objects Used to be... Just name them logically and consistently and you'll be fine... Show quote "Pat" wrote: > Hi folks. I know the official recommendation is to not begin stored > procedure names with "sp". But, is that case sensitive? Is it ok to start > them with "SP" in caps? > > Pat > > > > ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- > http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups > ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- > And why shouldn't SQL Server Objects be named with identification prefixes?
Is that an opinion or is there a reason? Obviously they don't need to be. But it seems to make things easier. First of all, that helps separate out the system objects from my objects when looking in enterprise manager. Secondly, It quickly tells me what an object is. I kinda like it. But if there's a reason why I shouldn't be doing it, it would be nice to know. Show quote "CBretana" <cbretana@areteIndNOSPAM.com> wrote in message ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----news:0ECABDA3-6F94-4049-93E4-EA4B040DB5DB@microsoft.com... > sp stands for "System Procedure", not "Stored Procedure", and this prefix > (actually "sp_") is specifically recognized by SQL Server, and, allows a > stored Proc with this prefix, located in teh master database, ti be > accessible from any other database on the server... Whether the Character > Collation (Case Sensitive or not) of your server would affect whther SP_ > is > also subject to this functional distinction, or not, There is not reason > to > use either prefix for your stored procs... Sql Objects should not be named > with "Object-Type" identification prefixes, like MS Access objects or OOP > objects Used to be... Just name them logically and consistently and you'll > be > fine... > > > > "Pat" wrote: > >> Hi folks. I know the official recommendation is to not begin stored >> procedure names with "sp". But, is that case sensitive? Is it ok to start >> them with "SP" in caps? >> >> Pat >> >> >> >> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet >> News==---- >> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ >> Newsgroups >> ----= East and West-Coast Server Farms - Total Privacy via Encryption >> =---- >> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- First of all, naming standards, lie all stadards, as you properly note, just
opinion... Whatever works and is comfortable for the people who deal with it is just fine... Second, as far as "Separating System Procs from User Procs, The only place system procs should be is in the master DB or in the msdb DB, It's a contradiction in terms t ohave a system proc in a user database. No Proc in a user database can be accessed from another database like a System Proc can be when it is properly named and stored in Master... And Why would you put User Procs in Master? So the two should *never* (with all the caveats that go with using that word) be togehter in the first place... Second, although it's certainly up to you, there is no where in EM where Objects of different types are displayed together.... Of what use is it to put sp_ as a prefix on Stored Procs when all the objects in the stored proc window will start with sp_? If you want to put a prefix on them to group them into logical groups, that's useful, (SQL2005 will allow you to create those sorts of logical groups without using prefixs) I remember I used to add a z at the beginning of stored procs I created that were only for my use, and not part of the Production system codebase, so they would go to the end in sort list, and I *knew* they were deletable and were not part of the production system... So the answer is -- There is no reason not to... If there IS a reason to do so, by all means consider it... But Identfying what type of object isomething is is not a *reasonable* reason, not when just about every tool out there already does that for you without artificial object prefixes... P.S. BTW, The consensus, even within the OOP community is shifting away from the naming style of Type Identifying Object prefixes that was common in the 80s & 90s. Modern tools make this nowhere near as useful as it was when using the development tools of 10 years ago.. Pat" wrote: Show quote > And why shouldn't SQL Server Objects be named with identification prefixes? > Is that an opinion or is there a reason? Obviously they don't need to be. > But it seems to make things easier. First of all, that helps separate out > the system objects from my objects when looking in enterprise manager. > Secondly, It quickly tells me what an object is. I kinda like it. But if > there's a reason why I shouldn't be doing it, it would be nice to know. > > > > "CBretana" <cbretana@areteIndNOSPAM.com> wrote in message > news:0ECABDA3-6F94-4049-93E4-EA4B040DB5DB@microsoft.com... > > sp stands for "System Procedure", not "Stored Procedure", and this prefix > > (actually "sp_") is specifically recognized by SQL Server, and, allows a > > stored Proc with this prefix, located in teh master database, ti be > > accessible from any other database on the server... Whether the Character > > Collation (Case Sensitive or not) of your server would affect whther SP_ > > is > > also subject to this functional distinction, or not, There is not reason > > to > > use either prefix for your stored procs... Sql Objects should not be named > > with "Object-Type" identification prefixes, like MS Access objects or OOP > > objects Used to be... Just name them logically and consistently and you'll > > be > > fine... > > > > > > > > "Pat" wrote: > > > >> Hi folks. I know the official recommendation is to not begin stored > >> procedure names with "sp". But, is that case sensitive? Is it ok to start > >> them with "SP" in caps? > >> > >> Pat > >> > >> > >> > >> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet > >> News==---- > >> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ > >> Newsgroups > >> ----= East and West-Coast Server Farms - Total Privacy via Encryption > >> =---- > >> > > > > ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- > http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups > ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- > Neither. This is SQL, the 21-st century and the era of data modeling;
this not Cobol or BASIC. The compiler does not need prefixes to make the parsing easily. Well, actually, SQL Server and the "sp_" crap is a few decades behind the curve on that one. When you name a procedure, you tell the poor bastard that has to maintain your code what it does. That means a name in the pattern of "<verb><object>" for procedures, with the SQL engine as the implied subject. Think about <verb>'s -- update, insert, delete, summarize, translate, etc. The <object> part does not have to be a table name, but a data model element -- NewCustomer, StudentGradeHistory, etc. ALWAYS tell me what something is or what something does at the LOGICAL level; do not tell where it is used, how it is used, implemented or stored at the PHYSICAL level. What does it mean in the logical data model? Get a copy of SQL PROGRAMMING STYLE for some help. Think more abstractly.  |
|||||||||||||||||||||||
Other interesting topics