Old Dog, New Tricks

  • Cadavre (2/13/2012)


    Jeff Moden (2/13/2012)


    Heh... there are a lot of tried and true methods available in SQL Server that seem to be going by the wayside in favor of "slick" stuff. A good example of this is the PIVOT operator. A lot of folks became enamored with it simply because it was new and "cutting edge". Many folks don't even know the old CROSS TAB technique even exists even though it's usually faster code and, IMHO, easier to read and understand.

    Although I absolutely agree that you have to understand and delve into the new stuff, I many times feel that we should "Teach new dogs old tricks". 😉

    It's a two way street though, really.

    I work with several "old dogs" that haven't kept their knowledge up to date. I'm happy to learn all I can from them and occasionally come across a technique that I haven't used before (although in the last 6 months or so that has started to get much rarer), however they don't seem all that interested in learning the newer techniques either from me or from other sources. For me, it's all about using the right tool for the job.

    That IS a problem, indeed. Like I implied in my previous post, the old dog has to learn some new tricks, as well, because some of the new methods really are slick. The additional functionality of SUM() OVER in 2012 is a good example. ROW_NUMBER() OVER (and the other Windowing Functions) was a great exammple for 2005. I'd have to kill something if they ever tried to take that away. I still run into even some "new dogs" that don't fully understand those simple concepts.

    Then, there's "counting Recursive CTEs". They could have done a whole lot better with those. Lots of "new dogs" have jumped on that bandwagon and it takes an "old dog" to get them to really look at how bad they can be.

    --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)
    Intro to Tally Tables and Functions

  • Replying to the article: the horrible *= and =* syntax is finally dead in SQL Server 2012 (no 80 compatibility). Semicolons are generally a good thing, but I don't go as mad with them as Gus does. One at the 'natural' end of the statement is good enough for me. As for the alias = column syntax, I have much preferred this for a very long time, but it is a personal preference and I will happily write code to whatever standard the person paying for it requires.

  • SQL Kiwi (2/13/2012)


    Replying to the article: the horrible *= and =* syntax is finally dead in SQL Server 2012 (no 80 compatibility). . . .

    Paul, what do you mean by '=* syntax'? It does not ring a bell. I searched MSDN for it, no hit.

    Thanks.

  • Revenant (2/13/2012)


    SQL Kiwi (2/13/2012)


    Replying to the article: the horrible *= and =* syntax is finally dead in SQL Server 2012 (no 80 compatibility). . . .

    Paul, what do you mean by '=* syntax'? It does not ring a bell. I searched MSDN for it, no hit.

    Thanks.

    Outer join syntax

    select a.ID, b.ID

    from a, b

    where a.id =* b.id

    =* is a right outer join

    *= is a left outer join.

  • implicit outter joins are no more in SQL 2012?:w00t:

  • Steve Jones - SSC Editor (2/13/2012)


    Revenant (2/13/2012)


    SQL Kiwi (2/13/2012)


    Replying to the article: the horrible *= and =* syntax is finally dead in SQL Server 2012 (no 80 compatibility). . . .

    Paul, what do you mean by '=* syntax'? It does not ring a bell. I searched MSDN for it, no hit.

    Thanks.

    Outer join syntax

    select a.ID, b.ID

    from a, b

    where a.id =* b.id

    =* is a right outer join

    *= is a left outer join.

    Thanks, Steve.

    Well, it is no longer documented for 2008 and beyond. I never used it, I guess I will not miss it.

  • jcb (2/13/2012)


    implicit outter joins are no more in SQL 2012?:w00t:

    Yes:

    http://msdn.microsoft.com/en-us/library/ms144262(v=sql.110).aspx

    And a good thing too.

  • SQL Kiwi (2/13/2012)


    jcb (2/13/2012)


    implicit outter joins are no more in SQL 2012?:w00t:

    Yes:

    http://msdn.microsoft.com/en-us/library/ms144262(v=sql.110).aspx

    And a good thing too.

    Agreed - it was a bad thing to overload *=.

  • Thanks Paul,

    I never though that I would live to see this day.

    Sorry while tears drops at the keyboard but...

    Too many sad bugs and bad coding I found writed with these horrible syntax.

  • SQL Kiwi (2/13/2012)


    Replying to the article: the horrible *= and =* syntax is finally dead in SQL Server 2012 (no 80 compatibility). Semicolons are generally a good thing, but I don't go as mad with them as Gus does. One at the 'natural' end of the statement is good enough for me. As for the alias = column syntax, I have much preferred this for a very long time, but it is a personal preference and I will happily write code to whatever standard the person paying for it requires.

    I actually don't go as mad with them as my example had. I've never put one on "BEGIN", for example. Not sure if it will be required there someday, but it seems counter-intuitive to me to have one. BEGIN doesn't end a statement in my mind.

    - 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

  • SQL Kiwi (2/13/2012)


    As for the alias = column syntax, I have much preferred this for a very long time, but it is a personal preference and I will happily write code to whatever standard the person paying for it requires.

    +1. I prefer that format, as well. I've also found that most companies/customers don't have a standard and are flatout astounded to find any kind of a thoughtful and consistent format and comments.

    --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)
    Intro to Tally Tables and Functions

  • jcb (2/13/2012)


    Thanks Paul,

    I never though that I would live to see this day.

    Sorry while tears drops at the keyboard but...

    Too many sad bugs and bad coding I found writed with these horrible syntax.

    Heh... even without that bit of nightmarish code, I still find the same to be true... "sad bugs" and "bad coding".

    --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)
    Intro to Tally Tables and Functions

  • Jeff Moden (2/13/2012)


    ...

    Heh... even without that bit of nightmarish code, I still find the same to be true... "sad bugs" and "bad coding".

    Sure, someday I ill print "I see bad code" in a T-shirt.:-D

    But that remember me hot discussions with a team of old dogs. My point at the time was to drop using implict joins.

    I'm pretty sure they are still coding that way.

    I hope none is working in air traffic control or ICBM launch sequences.

  • jcb (2/14/2012)


    Jeff Moden (2/13/2012)


    ...

    Heh... even without that bit of nightmarish code, I still find the same to be true... "sad bugs" and "bad coding".

    Sure, someday I ill print "I see bad code" in a T-shirt.:-D

    But that remember me hot discussions with a team of old dogs. My point at the time was to drop using implict joins.

    I'm pretty sure they are still coding that way.

    I hope none is working in air traffic control or ICBM launch sequences.

    I'd buy that t-shirt! 😛

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work (2/14/2012)


    jcb (2/14/2012)


    Jeff Moden (2/13/2012)


    ...

    Heh... even without that bit of nightmarish code, I still find the same to be true... "sad bugs" and "bad coding".

    Sure, someday I ill print "I see bad code" in a T-shirt.:-D

    But that remember me hot discussions with a team of old dogs. My point at the time was to drop using implict joins.

    I'm pretty sure they are still coding that way.

    I hope none is working in air traffic control or ICBM launch sequences.

    I'd buy that t-shirt! 😛

    I might too but it would make me feel slightly cross whenever I put it on.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 15 posts - 76 through 90 (of 92 total)

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