Re: Transaction Oriented Architecture (TOA)

Thomas Gagne wrote:
topmind wrote:
<snip>

I am still not understanding your scenario and why or why not it would
require an app change. Since I don't use classes, if a DB change does
not affect a field that an app or module uses, I don't have anything to
change. Perhaps Classes are your problem, not databases. blOOt at work.
If your classes have to mirror the DB out of OOP purity or obsession
with compile-time checking, then you have committed yourself to a
wasteful dance. My app usually does not change if it does not actually
*use* a given field.


Your DB has an account table with (accountNumber, balanceAmount, and
other fields) and a transaction table showing every change to
accountNumber and balanceAmount. To speed queries using account
balances from any day since its opening you create a dailyAccountBalance
table with (endingDate, accountNumber, balanceAmount). Realizing
balanceAmount is needlessly redundant between the account and
dailyAccountBalance tables you decide to remove account.balanceAmount
and replace it with a join to the dailyAccountBalance table where
endingDate = TODAY.

Every select from your account table is now broken.

Now, some people may think the change unwarranted or not worth the cost
of updating the applications's SQL. Of course, if everything were
behind a stored procedure it wouldn't be a problem cause an procedure's
implementation can change without changing its interface (calling
parameters or result columns)

Others may think a view is just as handy--which is almost true. Except
that if I want to record what everyone does in a transaction history
table I need to do other MACRO things a view doesn't allow for. Which
is fine 'cause I can use stored procedures.

I am not sure why a view would not work.

Let me see if I got this strait: You removed the "current" summary
table because we decided to sum as-needed instead, using a new daily
table (a more fine-grained summary). Correct?

Then the summary table can be turned into a view with the same columns
as the no-longer-used Current_Summary table. Recording every
transaction is a separate issue, isn't it? The daily table gets its
info from per-day sums of individual transactions, but the changed
queries don't have to know about that, correct? If a few queries need
direct access to the daily or individual transaction table, then they
do. Just because a few stragglers cannot use views does not mean the
majority can't. I've noticed a roughly 9-to-1 ratio of reading queries
to writing queries in most shops. The drawbacks of views will thus only
extend to about 10% of all queries that use the affected tables on
average.


--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

-T-

.

Relevant Pages

  • Re: New Method for Authenticated Public Key Exchange without Digital Certificates
    ... have the account disabled. ... then the next time you do a financial transaction ... ... eventually arrives at your financial institution ... ... in order to do credit card transactions, the merchant has to ...
    (sci.crypt)
  • Re: ComboBox Problem... Please, help me out!
    ... and tblTransDtl (transaction detail). ... You also have tables for SheetRegister and Account. ... Every sheet belongs to an only single ...
    (microsoft.public.access.formscoding)
  • Re: Query for Subform - G/L Account Transactions (Access XP)
    ... GLID COUNTER NOT NULL, -- a Counter is an AutoNumber ... xact_date DATETIME NOT NULL, -- transaction date ... Allow the user to select the description, reference, and transaction ... account in my chart of accounts. ...
    (microsoft.public.access.queries)
  • Re: Factories and lazy objects
    ... >>rules and policies for instantiation of the object and its ... > table, get the Account from the MainFrameConnection object, and pass it to ... > sheild the Account from the mainframe because there are planned upgrades to ... >>I have a hard time imagining a business environment where Transaction ...
    (comp.object)
  • Re: Query for Subform - G/L Account Transactions (Access XP)
    ... GLID COUNTER NOT NULL, -- a Counter is an AutoNumber ... xact_date DATETIME NOT NULL, -- transaction date ... Allow the user to select the description, reference, and transaction ... This form has several tabs (details, accounting rules, notes, etc) that are all tied together by the account number. ...
    (microsoft.public.access.queries)