Re: Design Strategy WAS: High-Profile Advocacy

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

> 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?
>

Josh, I think you and I are too much like DBA's and not enough like java
app developers. I always feel more comfortable putting logic into the
database so that I can write multiple apps in multiple languages against
it.

> > 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?
>

cause thats where the data is and the data is often the one thing that
can't be replaced so they have to feel comfortable. you want to make
sure your data is protected, and you don't want to swapping database
every six months because doing that means take your data out of a nice
container and hoping nothing gets munged in transit.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL