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

Josh,

> Nope, I'm still not communicating, I guess. Lemme give some examples:
>
You are communicating just fine. But I think we come from very different
backgrounds.

> 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.
>
Still an abstraction might be worth it for many ISV's. The refactoring you
mention is only needed if you don't cater for the independence from the very
start.

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.

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). And for an ISV, it's generally worth to go that route since many
customers have strict policies regarding databases.

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.

Kind regards,

Thomas Hallgren