|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Which syntax is better in SQL?response. In my code below, 1) Is it necessary to put things in brackets? Since we use Hungarian notation, we'll never have a naming conflict with a SQL reserved keyword. 2) Is it necessary to preface with "dbo"? 3) Should [public] be in brackets or not? I notice if I take them off, word turns blue. Is that good or bad? CREATE PROCEDURE [dbo].[stpSelectEmployee] ( @EmployeeID int ) AS SELECT e.LastName FROM tblEmployeer AS e WHERE e.ID = @EmployeeID GO GRANT EXECUTE ON [dbo].[stpSelectEmployee] TO [public] GO Thanks, Ron Cook 1. No, not necessary to use brackets. However, doing so insultates one from
conflicts between object names and reserved words and/or illegitimate names. Many of the tools will enclose in brackets perforce to prevent problems. And stop using Hungarian notation for SQL object names. All Best Practices and conventions mitigate against Hungarian. Use meaningful names with Pascal case. (Hungarian is in disfavor for application languages, and has never been in vogue with SQL.) 2.No, not necessary -execpt for function calls. However, it does seem to quell any issues with objects having been created without using dbo in the creation. Some will argue that there is a small performance 'boost' in using dbo. The system doens't have to check to see if there is an similar object name that would be owned by the current user (e.g., myname.objectname. The performance hit is so small that it would be difficult to measure.) There are legitimate circumstances where other than dbo is the object owner. But in most situations, all objects should be created as dbo.(objectname), and then using dbo in the call/reference add a level of efficiency. 3. [Public] -same issue with [1] above. It's a reserved word so brackets make it's usage perfectly clear. However, in the context of a GRANT statement, it's usages is appropriate without brackets. Color coding assists in visually checking code while writing the code -it may be a help or hinderance depending upon your mood and the alignment of the planets. -- Show quoteArnie Rowland* "To be successful, your heart must accompany your knowledge." "Ronald S. Cook" <rc***@westinis.com> wrote in message news:eLpf4VvpGHA.4032@TK2MSFTNGP03.phx.gbl... > Three quick questions on SQL syntax if you don't mind. I appreciate your > response. > > In my code below, > > 1) Is it necessary to put things in brackets? Since we use Hungarian > notation, we'll never have a naming conflict with a SQL reserved keyword. > 2) Is it necessary to preface with "dbo"? > 3) Should [public] be in brackets or not? I notice if I take them off, > word turns blue. Is that good or bad? > > CREATE PROCEDURE [dbo].[stpSelectEmployee] > > ( > > @EmployeeID int > > ) > > AS > > SELECT e.LastName > > FROM tblEmployeer AS e > > WHERE e.ID = @EmployeeID > > GO > > GRANT EXECUTE ON [dbo].[stpSelectEmployee] TO [public] > > GO > > > > Thanks, > > Ron Cook > > Arnie,
Regards point 2, there is more than only a small performance 'boost'. SQL Server will create separated execution plans for each user, resulting in non-reuse of query plans, when implicit name resolution is involved becasue of unqualified object names. See "syscacheobjects (uid)" in BOL. This behave the same for SQL Server 2000 and 2005. Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005 http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx AMB Show quote "Arnie Rowland" wrote: > 1. No, not necessary to use brackets. However, doing so insultates one from > conflicts between object names and reserved words and/or illegitimate names. > Many of the tools will enclose in brackets perforce to prevent problems. > > And stop using Hungarian notation for SQL object names. All Best Practices > and conventions mitigate against Hungarian. Use meaningful names with Pascal > case. (Hungarian is in disfavor for application languages, and has never > been in vogue with SQL.) > > 2.No, not necessary -execpt for function calls. However, it does seem to > quell any issues with objects having been created without using dbo in the > creation. Some will argue that there is a small performance 'boost' in > using dbo. The system doens't have to check to see if there is an similar > object name that would be owned by the current user (e.g., > myname.objectname. The performance hit is so small that it would be > difficult to measure.) There are legitimate circumstances where other than > dbo is the object owner. But in most situations, all objects should be > created as dbo.(objectname), and then using dbo in the call/reference add a > level of efficiency. > > 3. [Public] -same issue with [1] above. It's a reserved word so brackets > make it's usage perfectly clear. However, in the context of a GRANT > statement, it's usages is appropriate without brackets. Color coding assists > in visually checking code while writing the code -it may be a help or > hinderance depending upon your mood and the alignment of the planets. > > -- > Arnie Rowland* > "To be successful, your heart must accompany your knowledge." > > > > "Ronald S. Cook" <rc***@westinis.com> wrote in message > news:eLpf4VvpGHA.4032@TK2MSFTNGP03.phx.gbl... > > Three quick questions on SQL syntax if you don't mind. I appreciate your > > response. > > > > In my code below, > > > > 1) Is it necessary to put things in brackets? Since we use Hungarian > > notation, we'll never have a naming conflict with a SQL reserved keyword. > > 2) Is it necessary to preface with "dbo"? > > 3) Should [public] be in brackets or not? I notice if I take them off, > > word turns blue. Is that good or bad? > > > > CREATE PROCEDURE [dbo].[stpSelectEmployee] > > > > ( > > > > @EmployeeID int > > > > ) > > > > AS > > > > SELECT e.LastName > > > > FROM tblEmployeer AS e > > > > WHERE e.ID = @EmployeeID > > > > GO > > > > GRANT EXECUTE ON [dbo].[stpSelectEmployee] TO [public] > > > > GO > > > > > > > > Thanks, > > > > Ron Cook > > > > > > > Ronald
> 1) Is it necessary to put things in brackets? Since we use Hungarian No, Don't use Hungarian notation> notation, we'll never have a naming conflict with a SQL reserved keyword. > 2) Is it necessary to preface with "dbo"? Actually NO, however if you have an user that owner of the SP like John.SP it does makes sense to specify an owner 3) Should [public] be in brackets or not? I notice if I take them off, word > turns blue. Is that good or bad? Why do you want EXECUTE permission to the public?> Show quote "Ronald S. Cook" <rc***@westinis.com> wrote in message news:eLpf4VvpGHA.4032@TK2MSFTNGP03.phx.gbl... > Three quick questions on SQL syntax if you don't mind. I appreciate your > response. > > In my code below, > > 1) Is it necessary to put things in brackets? Since we use Hungarian > notation, we'll never have a naming conflict with a SQL reserved keyword. > 2) Is it necessary to preface with "dbo"? > 3) Should [public] be in brackets or not? I notice if I take them off, > word turns blue. Is that good or bad? > > CREATE PROCEDURE [dbo].[stpSelectEmployee] > > ( > > @EmployeeID int > > ) > > AS > > SELECT e.LastName > > FROM tblEmployeer AS e > > WHERE e.ID = @EmployeeID > > GO > > GRANT EXECUTE ON [dbo].[stpSelectEmployee] TO [public] > > GO > > > > Thanks, > > Ron Cook > > I might offer a different opinion than the other posters. By the way, blue
means a syntax or reserved word in sql.. Regarding using the dbo. - yes, always, require it... Always use the two part name. Yes, as Uri says, there is a small performance gain from not having to do double lookups. However two-part names are required to get the background advantages of SP plan sharing , and are required to schemabind anything.. It is a best practice to always use 2-part names when referencing any object name at the table level or higher. -- Show quoteWayne Snyder MCDBA, SQL Server MVP Mariner, Charlotte, NC I support the Professional Association for SQL Server ( PASS) and it''s community of SQL Professionals. "Ronald S. Cook" wrote: > Three quick questions on SQL syntax if you don't mind. I appreciate your > response. > > In my code below, > > 1) Is it necessary to put things in brackets? Since we use Hungarian > notation, we'll never have a naming conflict with a SQL reserved keyword. > 2) Is it necessary to preface with "dbo"? > 3) Should [public] be in brackets or not? I notice if I take them off, word > turns blue. Is that good or bad? > > CREATE PROCEDURE [dbo].[stpSelectEmployee] > > ( > > @EmployeeID int > > ) > > AS > > SELECT e.LastName > > FROM tblEmployeer AS e > > WHERE e.ID = @EmployeeID > > GO > > GRANT EXECUTE ON [dbo].[stpSelectEmployee] TO [public] > > GO > > > > Thanks, > > Ron Cook > > > Why are you guys so against Hingarian notation? I find it great for the
following: 1) Avoids naming conflicts 2) Objects sort nicely based on type 3) It's always very clear what you're working with What are the big reasons against it? Thanks, Ron Show quote "Wayne Snyder" <wayne.nospam.snyder@mariner-usa.com> wrote in message news:31FA5BC6-275F-4666-8110-67C3FCA89CA2@microsoft.com... >I might offer a different opinion than the other posters. By the way, blue > means a syntax or reserved word in sql.. > > Regarding using the dbo. - yes, always, require it... > > Always use the two part name. > > Yes, as Uri says, there is a small performance gain from not having to do > double lookups. However two-part names are required to get the background > advantages of SP plan sharing , and are required to schemabind anything.. > > It is a best practice to always use 2-part names when referencing any > object > name at the table level or higher. > -- > Wayne Snyder MCDBA, SQL Server MVP > Mariner, Charlotte, NC > > I support the Professional Association for SQL Server ( PASS) and it''s > community of SQL Professionals. > > > "Ronald S. Cook" wrote: > >> Three quick questions on SQL syntax if you don't mind. I appreciate your >> response. >> >> In my code below, >> >> 1) Is it necessary to put things in brackets? Since we use Hungarian >> notation, we'll never have a naming conflict with a SQL reserved keyword. >> 2) Is it necessary to preface with "dbo"? >> 3) Should [public] be in brackets or not? I notice if I take them off, >> word >> turns blue. Is that good or bad? >> >> CREATE PROCEDURE [dbo].[stpSelectEmployee] >> >> ( >> >> @EmployeeID int >> >> ) >> >> AS >> >> SELECT e.LastName >> >> FROM tblEmployeer AS e >> >> WHERE e.ID = @EmployeeID >> >> GO >> >> GRANT EXECUTE ON [dbo].[stpSelectEmployee] TO [public] >> >> GO >> >> >> >> Thanks, >> >> Ron Cook >> >> >> Ronald S. Cook wrote:
> Why are you guys so against Hingarian notation? I find it great for the Can you find any viewing area, within enterprise manager, query> following: > > 1) Avoids naming conflicts > 2) Objects sort nicely based on type > 3) It's always very clear what you're working with > > What are the big reasons against it? > > Thanks, > Ron > analyzer, or management studio, where objects of different types are displayed together? If you're looking at a line of SQL, and it has: exec dbo.foo then you can be fairly sure that foo is a stored procedure. Similarly, if you have select x,y,z from foo inner join bar on foo.a = bar.b then do you have any difficulty in knowing that a,b,x,y and z are all columns, and that foo and bar are (wait for it) either tables or views. This is about the only area where objects of two different types may be confused. But many argue that you should not distinguish between tables and (updateable) views. You can perform the same operations on them, so why would it matter what the underlying type is. So essentially, from a practical point of view, the argument against Hungarian is that, in this domain, it has no advantages and is just extra typing. Damien Well said.
Not only it is extra characters to type, it clutters up what you have to read without providing any useful information. -- Show quoteArnie Rowland* "To be successful, your heart must accompany your knowledge." "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message news:1152890594.372104.98750@75g2000cwc.googlegroups.com... > Ronald S. Cook wrote: >> Why are you guys so against Hingarian notation? I find it great for the >> following: >> >> 1) Avoids naming conflicts >> 2) Objects sort nicely based on type >> 3) It's always very clear what you're working with >> >> What are the big reasons against it? >> >> Thanks, >> Ron >> > Can you find any viewing area, within enterprise manager, query > analyzer, or management studio, where objects of different types are > displayed together? > > If you're looking at a line of SQL, and it has: > > exec dbo.foo > > then you can be fairly sure that foo is a stored procedure. Similarly, > if you have > > select x,y,z from foo inner join bar on foo.a = bar.b > > then do you have any difficulty in knowing that a,b,x,y and z are all > columns, and that foo and bar are (wait for it) either tables or views. > This is about the only area where objects of two different types may be > confused. But many argue that you should not distinguish between tables > and (updateable) views. You can perform the same operations on them, so > why would it matter what the underlying type is. > > So essentially, from a practical point of view, the argument against > Hungarian is that, in this domain, it has no advantages and is just > extra typing. > > Damien > I'm listening to your arguments objectively, you guys.. but so far I'm not
sold. I also like, when I'm emailing a co-worker, to be able to say "tblEmployee needs some tweaking and don't forget to make comments in stpSelectEmployeeByID" instead of having to explicitly say "Employee table needs some tweaking and don't forget to make comments in the stored proc SelectEmployeeByID" That may seem petty but we communicate so much about objects (intermixed with communications about our .NET code objects, that prefixing the Hungarian makes things more readable and succint to me. I guess to each his/her own then. Sounds like more a preference issue than anything structurally important. BTW, I had a client make me not use it on C# objects so frmEmployee became Employee and clsEmployee became.. oh darn... a conflict.. will have to go with... EmployeeClass (now THAT'S ugly). ALSO, form Login.aspx conflicts when you try to use the new Login control. Gotta name it something else now too. Hungarian solves all of this to me. Show quote "Arnie Rowland" <ar***@1568.com> wrote in message news:eUahet1pGHA.4912@TK2MSFTNGP05.phx.gbl... > Well said. > > Not only it is extra characters to type, it clutters up what you have to > read without providing any useful information. > > -- > Arnie Rowland* > "To be successful, your heart must accompany your knowledge." > > > > "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message > news:1152890594.372104.98750@75g2000cwc.googlegroups.com... >> Ronald S. Cook wrote: >>> Why are you guys so against Hingarian notation? I find it great for the >>> following: >>> >>> 1) Avoids naming conflicts >>> 2) Objects sort nicely based on type >>> 3) It's always very clear what you're working with >>> >>> What are the big reasons against it? >>> >>> Thanks, >>> Ron >>> >> Can you find any viewing area, within enterprise manager, query >> analyzer, or management studio, where objects of different types are >> displayed together? >> >> If you're looking at a line of SQL, and it has: >> >> exec dbo.foo >> >> then you can be fairly sure that foo is a stored procedure. Similarly, >> if you have >> >> select x,y,z from foo inner join bar on foo.a = bar.b >> >> then do you have any difficulty in knowing that a,b,x,y and z are all >> columns, and that foo and bar are (wait for it) either tables or views. >> This is about the only area where objects of two different types may be >> confused. But many argue that you should not distinguish between tables >> and (updateable) views. You can perform the same operations on them, so >> why would it matter what the underlying type is. >> >> So essentially, from a practical point of view, the argument against >> Hungarian is that, in this domain, it has no advantages and is just >> extra typing. >> >> Damien >> > > > That may seem petty but we communicate so much about objects (intermixed Then use Hungarian notation! Sheesh, there's no absolutely perfect right > with communications about our .NET code objects, that prefixing the > Hungarian makes things more readable and succint to me. answer. Most professionals, though, view the silly prefixes as, well, silly. When Celko says don't use IDENTITY, do you go and overhaul your entire schema to use something else? Of course not! The important thing about a naming convention is that it makes sense to you and your team, and it used consistently. That's it! If you want to prefix tables with ThisIsATableThatStores_Employees, ThisIsATableThatStores_Customers, then by all means, if you want to do all that extra typing to be sure that you're really accessing a table, nobody is stopping you. > I guess to each his/her own then. Sounds like more a preference issue Absolutely.> than anything structurally important. > BTW, I had a client make me not use it on C# objects These aren't C# objects! Are you going to name a table Employees and a stored procedure Employees? A Somehow, I suspect that most will 'guess' that an object name that contains
'SELECT', 'INSERT', 'UPDATE', or 'DELETE' is a sproc. Likewise with GET, PUT, CALC, etc. And of course, sometimes a word (table, sproc, etc.) may help the entry level person get up to speed. It continues to amaze me how many folks put 'Involved in setting Standards and Practices' on their resumes, and yet, there is so little conformance to the generally accepted Standards and Practices for a specific area. Almost all current White papers, books, and journals write that Hungarian is dead. It is not used in C#, it is no longer used in VB, and it has never been a standard (or even a wide spread practice) for SQL. -- Show quoteArnie Rowland* "To be successful, your heart must accompany your knowledge." "Ronald S. Cook" <rc***@westinis.com> wrote in message news:eXQEb11pGHA.2148@TK2MSFTNGP03.phx.gbl... > I'm listening to your arguments objectively, you guys.. but so far I'm not > sold. I also like, when I'm emailing a co-worker, to be able to say > > "tblEmployee needs some tweaking and don't forget to make comments in > stpSelectEmployeeByID" > > instead of having to explicitly say > > "Employee table needs some tweaking and don't forget to make comments in > the stored proc SelectEmployeeByID" > > That may seem petty but we communicate so much about objects (intermixed > with communications about our .NET code objects, that prefixing the > Hungarian makes things more readable and succint to me. > > I guess to each his/her own then. Sounds like more a preference issue > than anything structurally important. > > BTW, I had a client make me not use it on C# objects so frmEmployee became > Employee and clsEmployee became.. oh darn... a conflict.. will have to go > with... EmployeeClass (now THAT'S ugly). ALSO, form Login.aspx conflicts > when you try to use the new Login control. Gotta name it something else > now too. Hungarian solves all of this to me. > > > > > "Arnie Rowland" <ar***@1568.com> wrote in message > news:eUahet1pGHA.4912@TK2MSFTNGP05.phx.gbl... >> Well said. >> >> Not only it is extra characters to type, it clutters up what you have to >> read without providing any useful information. >> >> -- >> Arnie Rowland* >> "To be successful, your heart must accompany your knowledge." >> >> >> >> "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message >> news:1152890594.372104.98750@75g2000cwc.googlegroups.com... >>> Ronald S. Cook wrote: >>>> Why are you guys so against Hingarian notation? I find it great for >>>> the >>>> following: >>>> >>>> 1) Avoids naming conflicts >>>> 2) Objects sort nicely based on type >>>> 3) It's always very clear what you're working with >>>> >>>> What are the big reasons against it? >>>> >>>> Thanks, >>>> Ron >>>> >>> Can you find any viewing area, within enterprise manager, query >>> analyzer, or management studio, where objects of different types are >>> displayed together? >>> >>> If you're looking at a line of SQL, and it has: >>> >>> exec dbo.foo >>> >>> then you can be fairly sure that foo is a stored procedure. Similarly, >>> if you have >>> >>> select x,y,z from foo inner join bar on foo.a = bar.b >>> >>> then do you have any difficulty in knowing that a,b,x,y and z are all >>> columns, and that foo and bar are (wait for it) either tables or views. >>> This is about the only area where objects of two different types may be >>> confused. But many argue that you should not distinguish between tables >>> and (updateable) views. You can perform the same operations on them, so >>> why would it matter what the underlying type is. >>> >>> So essentially, from a practical point of view, the argument against >>> Hungarian is that, in this domain, it has no advantages and is just >>> extra typing. >>> >>> Damien >>> >> >> > > And like all things 'religious', once we accept a belief, it becomes
difficult to sway us from that belief. As Aaron wrote, the primary issue is: Does this facilitate communication with the project team and/or customers? If so, use it, if not, understand why, and consider altering the practice. -- Show quoteArnie Rowland* "To be successful, your heart must accompany your knowledge." "Arnie Rowland" <ar***@1568.com> wrote in message news:%23wbAbB2pGHA.1140@TK2MSFTNGP05.phx.gbl... > Somehow, I suspect that most will 'guess' that an object name that > contains 'SELECT', 'INSERT', 'UPDATE', or 'DELETE' is a sproc. Likewise > with GET, PUT, CALC, etc. And of course, sometimes a word (table, sproc, > etc.) may help the entry level person get up to speed. > > It continues to amaze me how many folks put 'Involved in setting Standards > and Practices' on their resumes, and yet, there is so little conformance > to the generally accepted Standards and Practices for a specific area. > > Almost all current White papers, books, and journals write that Hungarian > is dead. It is not used in C#, it is no longer used in VB, and it has > never been a standard (or even a wide spread practice) for SQL. > > -- > Arnie Rowland* > "To be successful, your heart must accompany your knowledge." > > > > "Ronald S. Cook" <rc***@westinis.com> wrote in message > news:eXQEb11pGHA.2148@TK2MSFTNGP03.phx.gbl... >> I'm listening to your arguments objectively, you guys.. but so far I'm >> not sold. I also like, when I'm emailing a co-worker, to be able to say >> >> "tblEmployee needs some tweaking and don't forget to make comments in >> stpSelectEmployeeByID" >> >> instead of having to explicitly say >> >> "Employee table needs some tweaking and don't forget to make comments in >> the stored proc SelectEmployeeByID" >> >> That may seem petty but we communicate so much about objects (intermixed >> with communications about our .NET code objects, that prefixing the >> Hungarian makes things more readable and succint to me. >> >> I guess to each his/her own then. Sounds like more a preference issue >> than anything structurally important. >> >> BTW, I had a client make me not use it on C# objects so frmEmployee >> became Employee and clsEmployee became.. oh darn... a conflict.. will >> have to go with... EmployeeClass (now THAT'S ugly). ALSO, form >> Login.aspx conflicts when you try to use the new Login control. Gotta >> name it something else now too. Hungarian solves all of this to me. >> >> >> >> >> "Arnie Rowland" <ar***@1568.com> wrote in message >> news:eUahet1pGHA.4912@TK2MSFTNGP05.phx.gbl... >>> Well said. >>> >>> Not only it is extra characters to type, it clutters up what you have to >>> read without providing any useful information. >>> >>> -- >>> Arnie Rowland* >>> "To be successful, your heart must accompany your knowledge." >>> >>> >>> >>> "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message >>> news:1152890594.372104.98750@75g2000cwc.googlegroups.com... >>>> Ronald S. Cook wrote: >>>>> Why are you guys so against Hingarian notation? I find it great for >>>>> the >>>>> following: >>>>> >>>>> 1) Avoids naming conflicts >>>>> 2) Objects sort nicely based on type >>>>> 3) It's always very clear what you're working with >>>>> >>>>> What are the big reasons against it? >>>>> >>>>> Thanks, >>>>> Ron >>>>> >>>> Can you find any viewing area, within enterprise manager, query >>>> analyzer, or management studio, where objects of different types are >>>> displayed together? >>>> >>>> If you're looking at a line of SQL, and it has: >>>> >>>> exec dbo.foo >>>> >>>> then you can be fairly sure that foo is a stored procedure. Similarly, >>>> if you have >>>> >>>> select x,y,z from foo inner join bar on foo.a = bar.b >>>> >>>> then do you have any difficulty in knowing that a,b,x,y and z are all >>>> columns, and that foo and bar are (wait for it) either tables or views. >>>> This is about the only area where objects of two different types may be >>>> confused. But many argue that you should not distinguish between tables >>>> and (updateable) views. You can perform the same operations on them, so >>>> why would it matter what the underlying type is. >>>> >>>> So essentially, from a practical point of view, the argument against >>>> Hungarian is that, in this domain, it has no advantages and is just >>>> extra typing. >>>> >>>> Damien >>>> >>> >>> >> >> > > I forgot another. Without Hungarian, tblSystem becomes System. Dang..
reserved work. Now I gotta but brackets around it everywhere. Hungarian means one more character but keeps everything very consistent. Like I said, I'm open minded. I know with VS 2005 Microsoft said go away from Hungarian and its not like its my nationality and I have a deep love for it. I just haven't heard enough good arguments to get me away from it. Ron Show quote "Arnie Rowland" <ar***@1568.com> wrote in message news:eUahet1pGHA.4912@TK2MSFTNGP05.phx.gbl... > Well said. > > Not only it is extra characters to type, it clutters up what you have to > read without providing any useful information. > > -- > Arnie Rowland* > "To be successful, your heart must accompany your knowledge." > > > > "Damien" <Damien_The_Unbelie***@hotmail.com> wrote in message > news:1152890594.372104.98750@75g2000cwc.googlegroups.com... >> Ronald S. Cook wrote: >>> Why are you guys so against Hingarian notation? I find it great for the >>> following: >>> >>> 1) Avoids naming conflicts >>> 2) Objects sort nicely based on type >>> 3) It's always very clear what you're working with >>> >>> What are the big reasons against it? >>> >>> Thanks, >>> Ron >>> >> Can you find any viewing area, within enterprise manager, query >> analyzer, or management studio, where objects of different types are >> displayed together? >> >> If you're looking at a line of SQL, and it has: >> >> exec dbo.foo >> >> then you can be fairly sure that foo is a stored procedure. Similarly, >> if you have >> >> select x,y,z from foo inner join bar on foo.a = bar.b >> >> then do you have any difficulty in knowing that a,b,x,y and z are all >> columns, and that foo and bar are (wait for it) either tables or views. >> This is about the only area where objects of two different types may be >> confused. But many argue that you should not distinguish between tables >> and (updateable) views. You can perform the same operations on them, so >> why would it matter what the underlying type is. >> >> So essentially, from a practical point of view, the argument against >> Hungarian is that, in this domain, it has no advantages and is just >> extra typing. >> >> Damien >> > > >I forgot another. Without Hungarian, tblSystem becomes System. What on earth does tblSystem store? Can't the name be a little less vague, with or without the useless prefix? A The utility of Hungarian notation in general, has been overblown for
historical reasons. The initial Hungarian notation was brought to Microsoft when its inventor Charles Simonyi ( from Hungary and then Xerox employee ) was hired as the Software Architect. Though initially it is used to prefix names with its meaning or semantics ( known as Apps Hungarian ) , but later undisciplined usage led to prefixing type name to the variable ( often termed as Systems Hungarian ). You can get more of the story here at: http://blogs.msdn.com/larryosterman/archive/2004/06/22/162629.aspx The original Simonyi paper can be found at: http://msdn.microsoft.com/library/en-us/dnvs600/html/hunganotat.asp Also see: http://www.byteshift.de/msg/hungarian-notation-doug-klunder These days many who never understood Hungarian in the first place, tend to place undue importance on the naming conventions based on "how" rather than "what". And this is no different in the database arena as well. Here are a few general reasons to often recommend against it: 1. Changing the type of a variable becomes a colossal pain with Hungarian notation, esp. when implicit type conversions become necessary. 2. At the data variable/ attribute level, there is no consistent Hungarian notation, whether one should use b- prefix represents bit or byte or boolean or bigint. 3. Interaction with programming languages that have a rich type system like ..NET often obfuscates the utility of Hungarian. 4. Hungarian often forces the programmer to often think in implementation details rather than in terms of semantics. 5. In a strongly typed language, Hungarian is often a prime source of misinterpretation -- essentially disguising a variable itself as a self commenting mechanism. -- Anith >> Why are you guys so against Hingarian notation? << The standards for data element names are set in ISO-11179. Besidesbeing hardt o read, Hingarian notation violates most of the principles for metadate set in that Standard. Just to add to what others are suggesting regarding the two-part naming
convention; start using it now. In SQL Server 2005, schemas are no longer simply associated with owners; you can have two tables with different schema membership, but the same name (ie., HR.Personnel vs IT.Personnel). Granted, I haven't found an actual "real-world" use for it yet, but I'm sure that someone will someday. Without the two-part naming syntax, it would be very easy to retrieve incorrect information. It's kinda like the semicolon; you don't have to have to have it now, but it's good practice to use it. Stu Ronald S. Cook wrote: Show quote > Three quick questions on SQL syntax if you don't mind. I appreciate your > response. > > In my code below, > > 1) Is it necessary to put things in brackets? Since we use Hungarian > notation, we'll never have a naming conflict with a SQL reserved keyword. > 2) Is it necessary to preface with "dbo"? > 3) Should [public] be in brackets or not? I notice if I take them off, word > turns blue. Is that good or bad? > > CREATE PROCEDURE [dbo].[stpSelectEmployee] > > ( > > @EmployeeID int > > ) > > AS > > SELECT e.LastName > > FROM tblEmployeer AS e > > WHERE e.ID = @EmployeeID > > GO > > GRANT EXECUTE ON [dbo].[stpSelectEmployee] TO [public] > > GO > > > > Thanks, > > Ron Cook  |
|||||||||||||||||||||||
Other interesting topics