Double-Entry Bookkeeping for SQL Programmers

Question

Double-Entry Bookkeeping for SQL Programmers

Tony Davis

SSCarpal Tunnel

Points: 4405
More actions
March 19, 2010 at 6:41 am

#146097

Comments posted to this topic are about the item Double-Entry Bookkeeping for SQL Programmers
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

OCTom SSChampion Points: 11785 More actions · Answer 1

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)

Tony Davis SSCarpal Tunnel Points: 4405 More actions · Answer 2

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.

SQLRNNR SSC Guru Points: 281334 More actions · Answer 3

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

Tobar SSCarpal Tunnel Points: 4876 More actions · Answer 4

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.

TomThomson SSC Guru Points: 104773 More actions · Answer 5

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

Jeff Moden SSC Guru Points: 1004361 More actions · Answer 6

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

Jeff Moden SSC Guru Points: 1004361 More actions · Answer 7

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)

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

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

Steve Jones - SSC Editor SSC Guru Points: 736255 More actions · Answer 9

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.

Tony Davis SSCarpal Tunnel Points: 4405 More actions · Answer 10

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.

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

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

TomThomson SSC Guru Points: 104773 More actions · Answer 12

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

Jeff Moden SSC Guru Points: 1004361 More actions · Answer 13

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)