Re: Design Strategy WAS: High-Profile Advocacy

Robert Treat wrote:

>On Thu, 2004-06-24 at 16:12, Josh Berkus wrote:
>
>
>>Thomas,
>>
>>
>>
>>>You are communicating just fine. But I think we come from very different
>>>backgrounds.
>>>
>>>
>>Nope, nope, I'm not. Sorry. I'm being completely obtuse.
>>
>>Ok, there's 2 knids of database independence:
>>
>>1) impelemtation of a full abstraction layer, including optimized query and
>>function calls for each class and method in the application, and often
>>switched query choices depending on the database system installed.
>>Implementation of schemas for each of several database systems to work with
>>this.
>>
>>2) "Dumbing down" your SQL calls to the point where they will run on almost
>>anything.
>>
>>It's (2) I was saying was "only useful for a limited range of web
>>applications" and (1) that "required a large budget".
>>
>>
>>
>
>Somewhere between 1 and 2 you have people designing schemas tailored to
>boosting performance on one database vs. another. For example, using
>count(*) table in postgresql apps that would be unneeded in my$ql, or
>using crazy table layouts to make up for a lack of views or partial
>indexes. Or maybe they add in extra application code to make up for a
>lack of triggers...
>
>
>
Actually, under the assumption that you require updateable views,
triggers, and functions to be supported by any database you want to
support (it doesn;t limit the playing field too much to require these
basic ideas), then you can abstract things simply by agreeing on an
interface and then providing the abstraction *in the database.* Then
only syntactic quirks need to be abstracted (PostgreSQL returns column
names in lower case, Firebird returns them in upper case, that sort of
thing). Again, you agree on a common interface, and if something
doesn't conform to the standard, you make it conform by abstracting the
difference. And the performance tweaks are hidden inside the box.

This means bending the app a little, and bending the database a bit more
so that they meet roughly at the point of greatest benefit.

Best Wishes,
Chris Travers