Re: Client/Server query strategy

In <3jnp3f$rrh_at_ef2007.efhd.ford.com> wmeahan_at_ef0424.efhd.ford.com (Bill Meahan) writes:

>Same table, different table -- doesn't matter. Doesn't affect just
 OLTP systems either.
>
>If Joe User expects the aggregated total he reads out of whatever table
 to accurately
>represent the total of items meeting certain critera, the two had damn
 well better match
>or Joe could be up a creek without a paddle if he makes a bad decision
 based on not
>knowing the difference. ("Gee, I wouldn't have written that $2,000,000
 check if I'd known
>the checking balance didn't show the check Jane wrote that left a
 balance of $0.49.")
>
>I'm no dogmatist, but in nearly 30 years of programming, from real-time
 control systems to
>material cost forecasting systems, the worst sins I've seen were all
 committed in the name of
>"performance." Yeah, performance IS important, but data integrity is
 even MORE important.
>If a given situation is such that there is NO data integrity risk
 involved in storing aggregated data
>and the performance gain is significant, then by all means store the
 aggregated table. Otherwise,
>don't bet your job or your company's future on it.
>

FYI The database in question will contain static information. It's a data warehouse that will only be updated monthly. No other updates at all.

Just out of curiousity, even in a heavy OLTP database, couldn't you insure that the detail and aggregate tables are always in sync via triggers or stored procedures? (If this is a dumb question, remember I'm an Oracle novice.)

        ><> Chuck Hamilton <>< Received on Fri Mar 10 1995 - 21:11:56 CET