August 19, 2008 at 8:36 pm
DB_Andrew (8/19/2008)
Instead of preaching your “RBAR” cliché and putting people down for doing it the wrong way why don’t you get off your soap box and make yourself helpful for a change and answer their questions and give them the proper set based solution. I see this countless times on here where you come in calling REBAR on people and linking to your articles and telling them they are wrong but you never giving them a real solution to the answer. You may as well just say RTFM and tell them to read books online.
Wow... bad day, huh? 😉
Alright... an explanation is deserved... You've not seen the countless times that I have given a written, coded solution along with test data to test against, performance comparisons, and the whole Alice's restaurant thing. In fact, my first article on Triangular Joins was actually just a smoothed over, full length copy of an actual post. Google it... you'll see. 😉 The reason why I wrote the articles is because people kept asking the same things over and over and it's a convenient place to point them to instead of copying and pasting the same answers to the same questions, over and over. The articles are broad enough and have enough code examples to cover many questions if people take a bit of time to study them.
If the WHILE loop is really that bad why would Microsoft include it in 5 versions of SQL Server over how many years?
Heh... Same reason why they added cursors, CLR's, and the ability to do correlated Sub-Queries to SQL Server... sometimes they are actually necessary. But, they're not necessary about 99.9999% of the time and most people make the mistake of giving up on the correct, set based solution too soon. 😉
Sorry you got so upset... I've just seen it way too many times where good folks listen to someone who says "Use a While loop (or some other form of RBAR) for now and go fix it later"... Couple of good friends followed that advice, got canned for the code failures in scalability that showed up 6 months later, and where labeled as "code monkeys" by many of the managers who, of course, talk to other folks in our fair trade. Was tough for them to find a job after that even though it wasn't their fault. I'd like to keep other people from going through that particular bit of computational heaven. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 19, 2008 at 10:17 pm
don't use GOTO, rather use COMEFROM.
---------------------------------------
elsasoft.org
August 19, 2008 at 11:00 pm
August 20, 2008 at 6:58 am
"COMEFROM"
YES !! My all-time favourite !
August 20, 2008 at 7:17 am
It’s all about the right tool for the job and what is acceptable performance wise. Sure there are other ways of accomplishing the same thing. If the WHILE loop is really that bad why would Microsoft include it in 5 versions of SQL Server over how many years?
Well, they've implemented GOTO, which has been deprocated since 1968
http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF
There's no reason to use goto, and few where there's not a better option than a WHILE
August 20, 2008 at 7:20 am
If I posed this question "should I sweep my driveway with a toothbrush or a hairbrush?' would it be more helpful to tell me to use a broom or the hairbrush?
August 20, 2008 at 8:20 am
"There's no reason to use goto" ...
I beg to differ.
I do have a use for GOTO -- provided DISCIPLINE is used to keep it readable.
Since this is forum on SQL Server 2000, which has no such thing as a "CATCH", I use the GOTO clause for error handling.
For instance:
[font="Courier New"]DECLARE @li_RetCode int
SET @li_RetCode = -666
INSERT INTO myTable2 .... SELECT * FROM myTable1 (you get the picture)
IF @@ERROR <> 0 SET @li_RetCode = -1 ELSE SET @li_RetCode = 0
IF @li_RetCode <> 0 GOTO AB_END
UPDATE myTable2 SET ... (you get the picture) -- STEP 2
IF @@ERROR <> 0 SET @li_RetCode = -2
IF @li_RetCode <> 0 GOTO AB_END
... other steps
AB_END:
RETURN @li_RetCode[/font]
Instead of:
[font="Courier New"]IF @li_RetCode = 0 BEGIN
UPDATE myTable2 SET ... (you get the picture) -- STEP 2
IF @@ERROR <> 0 SET @li_RetCode = -2
END
RETURN @li_RetCode[/font]
The value returned by the stored proc can at least indicate which step failed, aiding in debugging.
In cases where the code is nested in side a transaction, then I use the GOTO clause and handle the transaction (commit or rollback) at the end, just before exiting the stored proc.
Yes, I saw the infamous spaghetti coding when I started in the early 70's produced by sloppy programmers abusing the GOTO clause (at that time, I was also taught the Bubble Sort algorithm WITHOUT any caution regarding the existence of any other sorting algorithm and the need to consider the number of items to be ordered). Then the structure programming revolution happened and the now infamous GOTO clause was lynched publicly. Loop constructs were emphasized.
(Any other adolescent coders using Fortran writing something like IF Girl 36, 24, 36 CALL Her ? -- 90, 60, 90 cm). Oh yes, an implicit triple goto was allowed in Fortran.
But even structured programming did not prevent the crash of an orbital probe (circa 19950) when a missing conversion between feet and meters in the programming when through without anyone noticing).
As per the tag line which I am shamelessly stealing (too lazy to bother finding the name of the author), developing better languages intended to prevent idiocy is locked in an arms race with the universe producing "better" idiots, or something to that effect.
However powerful the language is, a sense of order and discipline is still required.
I do not want the GOTO construct banned anymore than I want to see the WHILE construct banned. There is a limit to protecting people against themselves. There may be infrequent occasions where they are useful. User education is the key.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply