April 21, 2010 at 9:51 am
Andrew Watson-478275 (4/21/2010)
At the risk of uttering a heresy, is SQL even the best place to do the comparison? Assuming the records are being keyed into some front-end system, might it not be better to do the comparison in there before the second record even gets saved?If it's an OO system, you could wrap the comparison nicely up into some kind of equals method on the object.
I believe the comparison should be handled by the app - easier, more efficient, and cleaner. This is one of those business rules type of things (IMHO). Thus I agree with you in this scenario.
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
April 21, 2010 at 10:34 am
Andrew Watson-478275 (4/21/2010)
At the risk of uttering a heresy, is SQL even the best place to do the comparison? Assuming the records are being keyed into some front-end system, might it not be better to do the comparison in there before the second record even gets saved?If it's an OO system, you could wrap the comparison nicely up into some kind of equals method on the object.
The database won't do the actual comparison (we'll need business logic and a user interface for that) but by all means the database should be the repository for data.
In this sort of situation, too many DBA's are scared of having "bad data" in their database. Any user input is potential subject to modification and correction, but by building the database in such a way as to facilitate and track those corrections you can have a much more robust system than you would if you denied storage of the data until it was "right".
For instance, say we handle the verification of the input at the application level ... not only would the business process be limited in terms of the timing of the multiple entries but you would end up with very little data about your data input process. If you keep all of the reconciliation data in your database, not only will you have the end product, you'll also be able to identify who has higher or lower input accuracy, average input attempts, time spent per record, etc. Although it would be possible to track those things in an application, you would essentially be creating your own database and you would still need to account for a potential change to the data you inserted in the database because you thought it was "right".
Viewing 2 posts - 46 through 46 (of 46 total)
You must be logged in to reply to this topic. Login to reply