Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum

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