Re: Transaction Oriented Architecture (TOA)
- From: "topmind" <topmind@xxxxxxxxxxxxxxxx>
- Date: 14 Dec 2006 21:04:35 -0800
Thomas Gagne wrote:
topmind wrote:
Thomas Gagne wrote:If you change any DDL you're going to explore for SQL. I doubt that if
<snip>
In that case then SQL separation is "bad" because it often forces you
to visit 2 different places to make changes: the app code and the SQL
area. If they are together in the same module, then you don't have to
do the Separation Texas Two Step. No hopping around = saved time.
What is the alleged bad scenario that separation protects us from?
SQL has leaked into the application you'll only be visiting two places.
You'll visit every place SQL was affected by the DDL change--if you can
find them.
Not necessarily. I tend to use a fair amount of SELECT asterisks if
there is not a large volume of result records. Plus, often the app will
change also if the schema changes such that we will be visiting the app
code such that we only have one module to change. Otherwise, you don't
need to change the SQL if the apps aren't using a new column. See
below.
<snip>I'm not concerned about single fields like SSN. I'm more concerned with
In the case of OO and
DB, when a mapping exists between the two, the nearer that mapping
approaches 1:1 the more tightly coupled the application and DB are. In
a 1:1 mapping nothing in the DB can be changed without affecting the
application, nor can anything be changed in the application data model
without affecting change in the DB.
Can you present a specific scenario? If you don't meta-tize the
elements (such as in a data or field dictionary table, or the ugly fad
of XML configs), then such would often be needed if one is dealing with
the same thing. If the Social Security Number (SSN) is stored in the
database, but the app also uses the SSN, then there is likely to be an
unavoidable coupling there.
a mapping of an Account class to an account table and their fields. If
the account table changes or some of its lesser-used columns moved to
another table then I have a maintenance problem. It matters little to
me if I'm editing XML configs, Java code, or anything else. Any update
that can be localized to the DB only, the happier I am--especially if I
don't have to build/ship/system-test a bunch of software.
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.
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
-T-
.
- Follow-Ups:
- Re: Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- 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
- Transaction Oriented Architecture (TOA)
- Prev by Date: book recommendation for UML
- Next by Date: HELO EVERUBODY!
- Previous by thread: Re: Transaction Oriented Architecture (TOA)
- Next by thread: Re: Transaction Oriented Architecture (TOA)
- Index(es):
Relevant Pages
|