Double-Entry Bookkeeping for SQL Programmers

  • Comments posted to this topic are about the item Double-Entry Bookkeeping for SQL Programmers

  • 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)

  • 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.

  • 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

  • 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.

  • 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

  • "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


    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)

  • 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


    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 (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.

  • 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.

  • 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.

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

  • 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


    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)

  • 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