March 19, 2010 at 6:41 am
Comments posted to this topic are about the item Double-Entry Bookkeeping for SQL Programmers
March 19, 2010 at 6:46 am
The idea is simply to write comparative tests into the code; you have the "proven but unsupported" production method and then, at its side, a very "safe" method that performs exactly the same calculation, on a small subset of the data.
Why wouldn't you use the safe method every time? It seems to me that if you have a method that works and is safe, why would you not use that? Maybe I'm missing the point completely. :hehe:
Go Badgers... (NCAA)
March 19, 2010 at 7:13 am
Performance - "alternative solutions are failing to meet performance targets"
Also, I don't think the idea only applies to cases where a technique is "unsupported". I think it's an interesting idea whenever performing a critical calculation, e.g. in a financial application.
Tony.
March 21, 2010 at 6:53 pm
This is an interesting idea. It could cause projects to be stretched out longer than desired (at least for a bit). However, it could reduce the number of defect reworks that needs to be done.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 22, 2010 at 6:27 am
Sure thing Polly 🙂 Management always allows time for
continuously revisiting and retesting your code and your assumptions
I like your thinking if it were a programmers world.
<><
Livin' down on the cube farm. Left, left, then a right.
April 4, 2010 at 3:46 am
Good editorial, and a very good point about techniques not officially supported against alternative (supported) methods.
One minor niggle some extent it reads as if defensive programming is only about doing a calculation (on a subset of the data) two ways and checking the results are the same. It isn't. One of the first steps is to make sure you have code for all the "this can't happen" situations; another is that you validate every input; yet another that you use recovery blocks, in multiple layers. Then there are domain-specific defensive coding techniques too: for example getting the correct order of computation to minimise the effect of rounding errors and of course that sort of calculation has to be done two ways on all the data not on a small subset, since a small subset won't produce runaway error accumulation; and if the two result sets are close enough for safety, taking average values over the two sets may be a good idea - for some definition of average.
Tom
April 4, 2010 at 2:35 pm
"double-entry bookkeeping"
Heh... I've run into "double-entry" methods many, many times at a fair number of companies. The problem is that some people do it wrong to make both entries. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2010 at 2:42 pm
skjoldtc (3/19/2010)
The idea is simply to write comparative tests into the code; you have the "proven but unsupported" production method and then, at its side, a very "safe" method that performs exactly the same calculation, on a small subset of the data.
Why wouldn't you use the safe method every time? It seems to me that if you have a method that works and is safe, why would you not use that? Maybe I'm missing the point completely. :hehe:
Considering the subject matter in the article, I suspect the article is about "proven but unsupported" things such as the "Quirky Update" methods. The problem is the definition of what is "safe" and what is not and it varies from one person to another. If the definition of "safe" is "something that is guaranteed to work forever", then almost all code will fail such an expectation due to deprecation of features in favor of supposedly better features.
Why would someone take a chance on something that could change in the future? Heh... ask a FoxPro user or a survivor of SQL Server 2000 sp4. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2010 at 2:52 pm
Jeff Moden (4/4/2010)
Considering the subject matter in the article, I suspect the article is about "proven but unsupported" things such as the "Quirky Update" methods.
I'm not sure it is...the last paragraph of the article says: "However, this shouldn't stop the defensive programmer from using proven techniques to which Microsoft prefers not to give its stamp of approval."
I took this article to be just another plug for Alex's book...published by RedGate Books 😉
People interested in a preview/sample should check out his blog entries on defensive programming.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 5, 2010 at 9:06 am
I'm not sure it was a plug as much as Tony was inspired by the book.
However I agree with Jeff. I'd bet that often people without a lot of experience might end up doing both sides incorrectly. I know that it happens in accounting all the time.
April 5, 2010 at 10:03 am
Steve is right: it was an idea inspired by working with Alex on his book. The editorial was not written with the sole purpose of plugging the book (and, in fact, the idea is not covered in the book).
However, Alex's book is certainly relevant, and I thought people might be interested to know about it.
Cheers,
Tony.
April 5, 2010 at 10:10 am
I think I was misled by a combination of the Related Articles links on the page (the top one takes you to the Editorial Review for the book), the link to the book in the article, and the frequent references to 'defensive programming'. The plugging appears to have been all in my mind.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 5, 2010 at 8:49 pm
Paul White NZ (4/5/2010)
I think I was misled by a combination of the Related Articles links on the page (the top one takes you to the Editorial Review for the book), the link to the book in the article, and the frequent references to 'defensive programming'. The plugging appears to have been all in my mind.
It was in my mind too. The article seemed to be incidentally about double entry book-keeping as an example of defensive programming which was the main topic, despite the title. Maybe we both have the same sort of warped mind?
Tom
April 5, 2010 at 9:37 pm
Tom.Thomson (4/5/2010)
Maybe we both have the same sort of warped mind?
Heh... 'zactly. And from what I've seen from your two folks posts in the past, it's not a bad thing. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 16, 2023 at 10:22 pm
This was removed by the editor as SPAM
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply