Re: Transaction Oriented Architecture (TOA)
- From: Thomas Gagne <tgagne@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 15 Dec 2006 06:29:18 -0500
topmind wrote:
<snip>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.
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.
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.
--
Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
.
- Follow-Ups:
- Re: Transaction Oriented Architecture (TOA)
- From: topmind
- Re: Transaction Oriented Architecture (TOA)
- References:
- Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- Re: Transaction Oriented Architecture (TOA)
- From: H. S. Lahman
- Re: Transaction Oriented Architecture (TOA)
- From: topmind
- Re: Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- Re: Transaction Oriented Architecture (TOA)
- From: topmind
- Re: Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- Re: Transaction Oriented Architecture (TOA)
- From: topmind
- Transaction Oriented Architecture (TOA)
- Prev by Date: HELO EVERUBODY!
- Next by Date: Re: book recommendation for UML
- Previous by thread: Re: Transaction Oriented Architecture (TOA)
- Next by thread: Re: Transaction Oriented Architecture (TOA)
- Index(es):
Relevant Pages
|