Old Dog, New Tricks

Question

Old Dog, New Tricks

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

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

Jeff Moden SSC Guru Points: 1004356 More actions · Answer 1

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)

Paul White SSC Guru Points: 150467 More actions · Answer 2

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.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Revenant SSC-Forever Points: 42467 More actions · Answer 3

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.

Steve Jones - SSC Editor SSC Guru Points: 736252 More actions · Answer 4

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.

jcb SSCertifiable Points: 6574 More actions · Answer 5

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

Revenant SSC-Forever Points: 42467 More actions · Answer 6

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.

Paul White SSC Guru Points: 150467 More actions · Answer 7

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.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Revenant SSC-Forever Points: 42467 More actions · Answer 8

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 *=.

jcb SSCertifiable Points: 6574 More actions · Answer 9

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.

GSquared SSC Guru Points: 260824 More actions · Answer 10

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

Jeff Moden SSC Guru Points: 1004356 More actions · Answer 11

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)

Jeff Moden SSC Guru Points: 1004356 More actions · Answer 12

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)

jcb SSCertifiable Points: 6574 More actions · Answer 13

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.

Rod at work SSC-Dedicated Points: 34008 More actions · Answer 14

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.

Gary Varga SSC Guru Points: 82166 More actions · Answer 15

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!!!