<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQLServerCentral.com
»
Editorials
»
Double-Entry Bookkeeping for SQL Programmers
14 posts, Page 1 of 2
1
2
»»
Double-Entry Bookkeeping for SQL Programmers
Rate Topic
Display Mode
Topic Options
Author
Message
Tony Davis
Tony Davis
Posted Friday, March 19, 2010 6:41 AM
Mr or Mrs. 500
Group: Administrators
Last Login: Wednesday, May 08, 2013 10:31 AM
Points: 511,
Visits: 945
Comments posted to this topic are about the item
Double-Entry Bookkeeping for SQL Programmers
Post #886302
OCTom
OCTom
Posted Friday, March 19, 2010 6:46 AM
SSCrazy
Group: General Forum Members
Last Login: Yesterday @ 12:56 PM
Points: 2,017,
Visits: 2,850
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
Tony Davis
Tony Davis
Posted Friday, March 19, 2010 7:13 AM
Mr or Mrs. 500
Group: Administrators
Last Login: Wednesday, May 08, 2013 10:31 AM
Points: 511,
Visits: 945
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
SQLRNNR
SQLRNNR
Posted Sunday, March 21, 2010 6:53 PM
SSCoach
Group: General Forum Members
Last Login: Monday, May 20, 2013 1:07 PM
Points: 18,733,
Visits: 12,332
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 2008
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
Tobar
Tobar
Posted Monday, March 22, 2010 6:27 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 169,
Visits: 553
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
L' Eomot Inversé
L' Eomot Inversé
Posted Sunday, April 04, 2010 3:46 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 2:27 AM
Points: 7,105,
Visits: 7,170
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
Que conclure à la fin de tous mes longs propos? C'est que les préjugés sont la raison des sots. (Voltaire, 1756)
Post #896373
Jeff Moden
Jeff Moden
Posted Sunday, April 04, 2010 2:35 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 7:51 PM
Points: 32,910,
Visits: 26,800
"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 "
R
ow-
B
y-
A
gonizing-
R
ow".
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."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #896474
Jeff Moden
Jeff Moden
Posted Sunday, April 04, 2010 2:42 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 7:51 PM
Points: 32,910,
Visits: 26,800
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 "
R
ow-
B
y-
A
gonizing-
R
ow".
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."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #896476
Paul White
Paul White
Posted Sunday, April 04, 2010 2:52 PM
SSChampion
Group: General Forum Members
Last Login: Today @ 1:49 AM
Points: 10,990,
Visits: 10,540
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
Steve Jones - SSC Editor
Steve Jones - SSC Editor
Posted Monday, April 05, 2010 9:06 AM
SSC-Dedicated
Group: Administrators
Last Login: Today @ 1:14 AM
Points: 31,433,
Visits: 13,746
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 »
14 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
