Hungarian notation convention

  • Hi everyone,

    Does anyone know where I can find a list of SQL data types and their Hungarian notation convention prefixes?

    I can find them for VB but not for SQL Server.

    Thanks,

    Jackal.

  • I don't think there's a standard reference.

    What I've seen, when I've seen it, has been:

    int

    tint

    sint

    bint

    dtm

    sdtm

    vc

    nvc

    char

    nchar

    dec

    num

    flt

    I don't use these, but they're what I've seen someone else use.

    - 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

  • Thanks GSquared.

    I've been looking all morning, with no joy.

    These should do me.

    Thanks again.

  • You're welcome.

    - 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

  • Gosh... you can use Hungarian notation if you want, but I think it's a real PITA. Let's say you have a table called something like tbl_MyTable. Someone redesigns a part of the system and the powers that be decide to use an indexed view instead of a table... and you have hundreds of stored procedures and GUI code instances where the code says "tbl_MyTable". Now what? You have 3 choices... find and change ALL the SQL Server and GUI code to the name of the new view, have a view with the "tbl_" prefix, or have a synonym (or passthrough view) named after a table even though it's a view.

    My recommendation is to never use Hungarian notation in SQL Server. It's just not needed and can be a real PITA if certain changes are required. 🙂

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Hi Jeff,

    Thanks for the reply, I am in complete agreeance with you. I've just been tasked with investigating it's usage potential.

    Jackal

  • Heh... include my post in your report on usage potential advising against using it.

    The only time I even come close to Hungarian notation is that I'll use a "pi" or "po" prefix on parameters in long stored procedures just to make the parameters easier to identify on long procs.... but I darned sure won't prefix one with something like "i" or "int" because even variables and parameters can change requirements of time. Imagine having a bunch of GUI or T-SQL that passes named parameters to a proc and ultimately ending up thinking something was other than an Int because even though the data type for the variable changed, you couldn't change the name of the parameter for fear of breaking GUI code that did use named parameters.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Just don't do it! As usual, Jeff is right. (And it is one of the worst ideas MS ever came up with.)

  • Agree Completely..

    not just tables and views though - I've inherited a Database written by a .Net developer and all my columns have prefixes and suffixes

    for example

    Mytable_Mycolumns_tinyint

    if i want to upgrade tinyint to int then my (inherited) app becomes a mess.... or i have to recode and recompile..

    even worse it's not really readable - given that you may know that table customer has an age field

    select max(tintage) from customer

    is not really great!!! even worse you have to know the data type before you can query the column

    one thing i can recommend though is try and use the Singular of Table and column names

    i.e

    Customer rather than customers

    Hobby rather than Hobbies

    yes the table is a collection of customer, but this can be easily confusing since apostrophee cannot be used in table names

    customershobbies could referernce all customers' hobbies or a single customer's hobbies

    instead stick to customerhobby

    MVDBA

  • Holy Moly, Mike... I thought I had it bad and the current job...

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • About using singular names for tables:

    Good idea.

    That name is then suitable for constructs such as

    ForEach Officer ...

    Looks pretty sorry when it is

    ForEach Officers.

  • Hi All,

    Hungarian notation is awful and inflexible. I have attached the database naming conventions I developed for our organisation (identifying references removed) and it's worked wonders for our databases and applications. Our previous databases were very messy and we often faced problems of changing data types etc as previously described by Jeff. Now, it's easier to read, code and maintain and the lagtime to get new developers up to speed has decreased as the notation is far more intuitive.

    Any constructive feedback is welcome.

    Jane

  • Excellent Jane!

    Can I steal it?

  • These are really nice and thorough. I think I'll borrow them too 🙂

  • Jeff Moden (9/23/2008)


    Heh... include my post in your report on usage potential advising against using it.

    The only time I even come close to Hungarian notation is that I'll use a "pi" or "po" prefix on parameters in long stored procedures just to make the parameters easier to identify on long procs.... but I darned sure won't prefix one with something like "i" or "int" because even variables and parameters can change requirements of time. Imagine having a bunch of GUI or T-SQL that passes named parameters to a proc and ultimately ending up thinking something was other than an Int because even though the data type for the variable changed, you couldn't change the name of the parameter for fear of breaking GUI code that did use named parameters.

    I put "_in" on the end of input parameters, "_out" on the end of output parameters, and "_inout" on bidirectional parameters. That's at the end of the name. Makes it very easy to tell, hundreds of lines into a complex proc, which things are parameters and which are locally declared variables.

    The data type is too easy to end up having to change, like you say, so I don't include that. Just the direction. I've found it very useful.

    - 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

Viewing 15 posts - 1 through 15 (of 58 total)

You must be logged in to reply to this topic. Login to reply