February 13, 2012 at 9:52 am
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
Change is inevitable... Change for the better is not.
February 13, 2012 at 10:40 am
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
February 13, 2012 at 11:13 am
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.
February 13, 2012 at 11:15 am
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.
February 13, 2012 at 11:17 am
implicit outter joins are no more in SQL 2012?:w00t:
February 13, 2012 at 11:21 am
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.
February 13, 2012 at 11:27 am
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
February 13, 2012 at 11:57 am
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 *=.
February 13, 2012 at 12:03 pm
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.
February 13, 2012 at 12:07 pm
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
February 13, 2012 at 5:06 pm
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
Change is inevitable... Change for the better is not.
February 13, 2012 at 5:08 pm
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
Change is inevitable... Change for the better is not.
February 14, 2012 at 3:22 am
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.
February 14, 2012 at 8:27 am
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.
February 15, 2012 at 6:27 am
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