Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum - Mailing list pgsql-advocacy

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".

Hopefully that's clearer.

> I could give you an example of financial vendor that deeply regret that
> they didn't listen to people that warned them about implementing all logic
> in Sybase stored procedures. I guess part of their decision was for the
> reasons you mention. In hindsight, and with a new design in place that
> performs extremely well, everyone asks why they didn't use an abstraction
> from the very start. Another fairly similar example is an ISV doing Supply
> Chain Execution. They are more or less dead now due to (unnecessary)
> database lock-in. It just wasn't possible to rewrite everything without
> starting from square one.

But how is this unique to databases?   Proprietary frameworks stagnate and
die, programming languages become obsolete, and infrastructure components get
discontinued.    Even open source projects can die, leaving the one company
still using their technology to try to keep the project up to date.

Just talk to anyone who built a massive application in Cold Fusion or
NetObjects in 1999.  Seemed like a pretty good idea to management then,
didn't it?

> I don't argue that data integrity should be dealt with in the database. And
> I don't argue that a heavy database dependency sometimes is the absolute
> best choice for the reasons you mention. All I'm saying is that in many
> cases, a careful analyze and design phase can result in a design where more
> than one database fit the needs. My guess is that many of the applications
> that you reckon would run very well if they where developed with a heavy
> dependency on PostgreSQL could gain comparable performance if they where
> heavily dependent on, say, Oracle. Now, to abstract the differences between
> the PostgreSQL and the Oracle solution without sacrificing performance nor
> integrity is perhaps not that hard (provided you do it from the very
> beginning).

I think you and I have different definitions of "not that hard".   Or maybe
it's just that my projects tend to have much more limited budgets and
timelines than yours.   The sort of abstraction you're talking about  -- type
#1 -- isn't real possible when the client wants the program 2 weeks ago, and
cares more about the bill than the software's longevity.

> And for an ISV, it's generally worth to go that route since
> many customers have strict policies regarding databases.

Why is this, anyway?   It puzzles me.    Managers don't tend to have opinions
on programming languages, web servers, network devices, or power supplies.
They'll use whatever is recommended.   But they have strong, immovable, and
often wholly uninformed opinions about databases.   Why?

> Independence is king if you develop for the J2EE market (not just for
> databases) and since I've been developing J2EE frameworks for many years I
> can assure you, it's not just a "limited class of web applications" that's
> being addressed.

Yeah, that would put you in type #1.

--
Josh Berkus
Aglio Database Solutions
San Francisco