Skip site navigation (1) Skip section navigation (2)

Re: Design Strategy WAS: High-Profile Advocacy

From: Chris Travers <chris(at)travelamericas(dot)com>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>,PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: Design Strategy WAS: High-Profile Advocacy
Date: 2004-06-25 05:58:46
Message-ID: 40DBBF16.3060907@travelamericas.com (view raw or flat)
Thread:
Lists: pgsql-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

In response to

pgsql-advocacy by date

Next:From: Richard HuxtonDate: 2004-06-25 10:59:12
Subject: Re: win32 binary downloads
Previous:From: Christopher BrowneDate: 2004-06-25 01:33:57
Subject: Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group