SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Hungarian Notation To Be or Not To Be


Hungarian Notation To Be or Not To Be

Author
Message
Ariadne
Ariadne
SSC-Addicted
SSC-Addicted (444 reputation)SSC-Addicted (444 reputation)SSC-Addicted (444 reputation)SSC-Addicted (444 reputation)SSC-Addicted (444 reputation)SSC-Addicted (444 reputation)SSC-Addicted (444 reputation)SSC-Addicted (444 reputation)

Group: General Forum Members
Points: 444 Visits: 168

The Data Warehouse team decided to use Hungarian notation on their SQL Server database (they aren't using the OLAP engine for their DW), and they decided to use the positional features of T-SQL in their code so if they had to change a datatype, column, etc. they wouldn't have to change their T-SQL code, because they'd rely on the position of the columns to handle any changes. They love Select *'s, Order by 1, and my all time favorite (sarcasm thick here) is the case statement in the Order By Clause. Having said that, now with .NET changing from passing parameters to SPROCs using a positional process, .NET requires you to name the parameter. So now, if you change an object's name in the database, you're more likely to have to crack your code all the way down to the web app. What are ya'll's thoughts on using Hungarian Notation rather than the good ol' Microsoft way, of calling it like it is?





Dave Poole
Dave Poole
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17256 Visits: 3403

I hate the idea of using positional arguments for code. How the hell are you supposed to know what ORDER BY 3 means without trawling through the code?

The argument put forward by your team seems to imply that field names are changing. I NEVER change field names precisely because doing so will break existing code.

If you rely on ordinal positions what happens if one of your team inserts a column? All of a sudden column 2 doesn't mean what you thought it should. This is also a good reason not to use SELECT *.

As far as using Hungarian notation my colleagues and I went through the debate and came out in favour of using it.

Yes, if the use of a variable changes then there are issues with altering the code but this is offset by looking at a variable and knowning just from looking at that variable name that it is a member of a class and pointer to a string.

If you have to change a variable within your code then search/replace tends to deal with it quite well thankyou very much, plus the compiler deals with the rest.

The main argument against Hungarian is that the variable names it produces are not tied to the code and can therefore become meaningless. You could say much the same thing about comments in your code and the comments are a damned site less connected to your code than the variables.

Unless you have meticulous documentation (sorry, I got distracted by the all England porcine aerobatic display team outside my window) tracking down what a variable is supposed to be is in reams of code is not a fun job. Even with documentation you are still going to be taking a break from your code to look it up!

Fashions come and go in IT and Hungarian is the equivalent of good strong shoes and sensible trousers.



LinkedIn Profile
www.simple-talk.com
Ralph Mallamace
Ralph Mallamace
SSC Veteran
SSC Veteran (234 reputation)SSC Veteran (234 reputation)SSC Veteran (234 reputation)SSC Veteran (234 reputation)SSC Veteran (234 reputation)SSC Veteran (234 reputation)SSC Veteran (234 reputation)SSC Veteran (234 reputation)

Group: General Forum Members
Points: 234 Visits: 1
Hungarian Notition is great for apps but not databases. You change one field and then you have to change 15 stored procedures, 13 views, 3 triggers, etc all because of a name change.

The only Hungarian Notation you shoud use if any is to stipulate between table and field and not any further than that (as in int or varchar) as this will not change. So if you had a table with customers in it call it tblCustomer and its fields could be fldCustomerId, fldFamilyName, fldGivenName, ... etc. You could change fldCustomerId from int to string and never have a major problem (I'm not saying you won't have a problem - but it won't be caused by a name change that for sure).

Besides a RDBMS isn't designed to communicate with .NET, VB, Java or whatever is being used. It's designed to store information and allow it to be retrieved in an effective way. So keep it effective. Don't allow the technology to dictate the design, good design should always shine through.
Scott Coleman
Scott Coleman
SSCertifiable
SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)

Group: General Forum Members
Points: 7512 Visits: 1534

Ditto to keeping Hungarian out of databases. I'm a firm believer in using it in code, but the only trace of it I use in databases is a 'vw' prefix to distinguish views from tables. These are two different objects that can often be used interchangably so it makes sense to do it, but it is unlikely you would confuse a field with a table.

Anyone using 'SELECT *' or 'ORDER BY 3' in production code should be retrained immediatly, preferably in a medieval dungeon.

But I have to admit to having found use for the CASE statement in the ORDER BY clause. I'm not sure why this would be considered evil, feel free to enlighten me.





Dave Poole
Dave Poole
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17256 Visits: 3403

I think the CASE in order by statements causes recompiles but I couldn't swear to it.

I prefix stored procedures with usp and functions with fn.

To be honest I have moved away from tbl and vw as prefixes for views and tables precisely because they are interchangeable.

An MS example would be the syslogins view.

I use Hungarian for variables and arguments within stored procedures but I don't bother for fields. It is just being over-zealous.



LinkedIn Profile
www.simple-talk.com
Sarah Dutkiewicz
Sarah Dutkiewicz
SSC-Addicted
SSC-Addicted (440 reputation)SSC-Addicted (440 reputation)SSC-Addicted (440 reputation)SSC-Addicted (440 reputation)SSC-Addicted (440 reputation)SSC-Addicted (440 reputation)SSC-Addicted (440 reputation)SSC-Addicted (440 reputation)

Group: General Forum Members
Points: 440 Visits: 263

I prefer to keep Hungarian Notation strictly to the applications and leave them out of the databases. However, we do end up using some variation of it when naming stored procedures and views. Our views are set aside by v_ or view_ and our stored procedures normally start with pr. Otherwise, tables and fields don't use the Hungarian Notation.

And if I saw a SELECT * or an ORDER BY 3 in any of the code I had to work with, I'd definitely be re-writing it. From a programmer's standpoint, I'd like to know just what I'm working with and * and 3 really don't help.


Dave Poole
Dave Poole
SSCoach
SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)SSCoach (17K reputation)

Group: General Forum Members
Points: 17256 Visits: 3403

One plus point on using prefixes is that you are unlikely to use a reserved word accidentally.

Given the plethora or languages out there it becomes ever easier to do this.

I had to debug a SSJS app and found that someone had used a variable name called "mid".



LinkedIn Profile
www.simple-talk.com
R. Kevin Gunther-Canada
R. Kevin Gunther-Canada
SSC Veteran
SSC Veteran (270 reputation)SSC Veteran (270 reputation)SSC Veteran (270 reputation)SSC Veteran (270 reputation)SSC Veteran (270 reputation)SSC Veteran (270 reputation)SSC Veteran (270 reputation)SSC Veteran (270 reputation)

Group: General Forum Members
Points: 270 Visits: 4

I do not think Hungarian Notation (or a variabt thereof) is bad at all for SQL. For example, we use the following prefixes:

tbl - standard data entry table
tlkp - static or semi static lookup table
ztbl - private system-level or application-level table (not for end-user eyes)
ttmp - semi-persistent temporary tables (usually reserved for load programs undergoing debugging or other testing)

We then insert some kind of DB or App identifier into the object name, so that we can easily differentiate items if a script happens to appear before us without a "USE" statement. Here, OSYS refers to the application or database.

tbl_OSYS_[name suffix]

We do this for all other objects (see below).

We also use this standard naming to deal with some problems in naming other objects. We used to do things like
spi - Insert SP
spd - Delete SP
... etc. However this became unwieldy in practice, as when developers tried to build classes, they really had to hunt around for items that were based on common objects. So we revised our practice to the following:

spa - All SPs that have are not dependent on other SPs.
sp0_ - All SPs which have dependencies
spz - All non-application specific SPs (related to db processes etc)

Then we modified our naming suffixes to Noun-Verb combinations, e.g.:

spa_OSYS_CustomerDetailGet
spa_OSYS_CustomerDetailAdd
spa_OSYS_CustomerDetailDelete
spa_OSYS_CustomerDetailSet
spa_OSYS_CustomerSummaryListGet

While we're at it, parameters and variables prefixes are structured as well:

@parm - input parameter
@pout - output parameter
@pio - input/output parameter
@var - local variable

While not ideal, and probably redundant in some ways, it works for us. It has really helped our developers, and even helps the DBAs easily and quickly identify objects associated with and app or database, even from a printout.

I'm sure folks can poke holes in this (there are more modern techniques, I'm know), and alternative ideas are welcome. But as Ken Getz once said [paraphrasing here], "use a naming convention, ANY naming convention, as long as it's logical and consistent."





Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search