Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Double-Entry Bookkeeping for SQL Programmers Expand / Collapse
Author
Message
Posted Friday, March 19, 2010 6:41 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Tuesday, July 8, 2014 9:43 AM
Points: 569, Visits: 1,009
Comments posted to this topic are about the item Double-Entry Bookkeeping for SQL Programmers
Post #886302
Posted Friday, March 19, 2010 6:46 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:47 PM
Points: 2,517, Visits: 3,716

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.

Go Badgers... (NCAA)
Post #886311
Posted Friday, March 19, 2010 7:13 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Tuesday, July 8, 2014 9:43 AM
Points: 569, Visits: 1,009
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.
Post #886337
Posted Sunday, March 21, 2010 6:53 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 4:09 PM
Points: 21,252, Visits: 14,960
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


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #887132
Posted Monday, March 22, 2010 6:27 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
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.
Post #887310
Posted Sunday, April 4, 2010 3:46 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 7:42 PM
Points: 8,567, Visits: 9,071
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
Post #896373
Posted Sunday, April 4, 2010 2:35 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:56 PM
Points: 36,774, Visits: 31,230
"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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #896474
Posted Sunday, April 4, 2010 2:42 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:56 PM
Points: 36,774, Visits: 31,230
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.


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

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #896476
Posted Sunday, April 4, 2010 2:52 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 10:58 AM
Points: 11,192, Visits: 11,097
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
SQL Server MVP
SQLblog.com
@SQL_Kiwi
Post #896478
Posted Monday, April 5, 2010 9:06 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 11:24 AM
Points: 33,088, Visits: 15,197
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #896772
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse