Re: Isolatable Concerns
- From: Thomas Gagne <tgagne@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 18 Dec 2006 10:06:07 -0500
topmind wrote:
<snip>Couldn't it also be that relationships exist and exploring relationships necessarily requires navigation?
It is not "abuses" but due to the fact that navigational is too
difficult for humans to navigate unless they reflect a familiar
physical environment or arrangement. This is why trees, physical
decomposition, and "pointer" path walking is popular with navigational
pushers.
If you factor it into subroutines or then you've pretty much created a flavor of stored-procedure--but without any of its benefits. You've satisfied structured programming, but have not mitigated any maintenance or deployment challenges.For 99.999% of items I'll stick with things should be
recorded once and only once. Everything else is redundant.
Why sprinkle SQL around, especially if its redundant?
Nobody here promoted redundant SQL. If there is redundancy, then
factor it to subroutines or views. Where, praytell, did you get that
notion?
Views are fun, and we use them as well, but their simplicity makes it difficult to tune for performance. What a view can do in a single SELECT statement can sometimes be more efficiently done with multiple statements and/or temporary tables.
<snip>Not necessarily. As CPUs have gotten faster and memory cheaper hardware has done more to promote developer convenience than methodologies have. A well crafted and easily maintained system written 18 months ago can now be twice as fast as then--without doing anything but moving to faster hardware. Hardware may have been the most expensive component for computing's first 30 years, but the tables have turned and now it is the least expensive. Better than optimizing hardware utilization is optimizing human utilization. Using more productive languages and processes like Smalltalk on modern hardware has never been as productive--and can only become more so in the future.
Performance versus developer convenience will always be a trade-off.
<snip>Denying separation's evidence does not make separation evidence-free. Given two applications, one with embedded SQL (static or automagically generated) and the other using DB procedures, my ability modify the DB and load a new fixed procedure that maintains its interface without having to ship a new application (and everything that entails) is proof of loose coupling's (separation's) value over tight coupling.
The change pattern profiles I see do not warrent separation.
Separation is an evidence-free fad, promoted by those who hate and/or
don't understand relational philosophy.
--
Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
.
- Follow-Ups:
- Re: Isolatable Concerns
- From: topmind
- Re: Isolatable Concerns
- References:
- Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- Re: Transaction Oriented Architecture (TOA)
- From: H. S. Lahman
- Re: Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- Re: Transaction Oriented Architecture (TOA)
- From: H. S. Lahman
- Re: Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- Re: Transaction Oriented Architecture (TOA)
- From: H. S. Lahman
- Re: Transaction Oriented Architecture (TOA)
- From: Thomas Gagne
- Isolatable Concerns (was: Transaction Oriented Architecture...)
- From: topmind
- Re: Isolatable Concerns
- From: Thomas Gagne
- Re: Isolatable Concerns
- From: topmind
- Transaction Oriented Architecture (TOA)
- Prev by Date: looking for a predicate hierarchy
- Next by Date: Re: Transaction Oriented Architecture (TOA)
- Previous by thread: Re: Isolatable Concerns
- Next by thread: Re: Isolatable Concerns
- Index(es):
Relevant Pages
|