Thomas,
> I agree, although good control can be achived using abstractions you
> sometimes need to compromize to get the best performance. I advocate you do
> this reluctantly rather than eagerly. Great performance can often be
> achived in conjunction with good separation of concern and use of sane
> design principles.
Nope, I'm still not communicating, I guess. Lemme give some examples:
Open-source online bulletin board: database independance with abstracted
classes. Portability is very important; data integrity is not.
Legal billing and accounting application: heavy database dependance.
Reasons: Security: data must be 99.9999% confidential and secure. This
requires extensive use of in-database security mechanisms.
Data Integity: transactions, especially in the GL, must be 99.9999%
trustworthy. This requires extensive use of in-database data integrity
controls.
Performance: main GL is expected to grow to 2 million records over the first
year. This requires database tuning and construction of queries aimed at
maximizing performance on the chosen platform.
"Database independence" is a strategy which is suitable for a limited class of
web applications, and not much else.
One can "abstract" the considerations in the 2nd example. However, it's an
enormous amount of work; it amounts to re-implementing the application on
each target platform, which only really the display code being the same; all
of the middleware which touches the database will have to be refactored.
I've seen some very large apps which did this, but it's not cheap.
--
Josh Berkus
Aglio Database Solutions
San Francisco
