From: "Uwe C. Schroeder" <uwe@oss4u.com>
Organization: OSS4U, LLC
To: Andrew Sullivan <ajs@crankycanuck.ca>,
	pgsql-general@postgresql.org
Subject: Re: Replication
Date: Wed, 21 Apr 2004 14:39:05 -0800
User-Agent: KMail/1.5.3
References: <CAC2F23E-92AC-11D8-B5ED-000A95DE2550@ifrance.com>
	<40869207.8020509@Yahoo.com>
	<20040421172803.GA325@phlogiston.dyndns.org>
In-Reply-To: <20040421172803.GA325@phlogiston.dyndns.org>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <200404211539.06102.uwe@oss4u.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 21 April 2004 10:28 am, Andrew Sullivan wrote:
> On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:
> > for that is NOT performance. SAP spends that effort multiple times by
> > implementing their own, custom integrity control and data domain system
> > in the DB abstraction layer, to gain DB vendor independence. That
> > abstraction layer is larger than PHP and Apache together, so this
> > example is IMHO totally irrelevant for the typical MySQL user.
>
> Actually, I think it _is_ relevant.  It's proof, IMNSHO, that the
> strategy of "doing it in the client" is completely bankrupt.  It's
> one thing to do it this way if you have software which is a
> category-killer the way SAP is, because you can afford the overhead
> of all those developers doing all that extra work, and you can make
> your customers buy trillion-dollar hardware to run your bloated
> masterpiece.  The Rest Of Us, however, need to do things efficiently,
> and that means doing the work in the place where it is least likely
> to need to be checked again.  For most database applications, that's
> inside the database.  (I'll not now start my rant on the mess caused
> by developers who are careless with this principle.)

I concur. However the problem SAP had some 18years ago when they invented=
=20
their system were massive differences between databases. The scope they had=
=20
in mind didn't allow for whole database layers to be redundant just for the=
=20
sake of being able to talk to several database engines - ergo they wrote on=
e=20
layer and omitted using vendor dependant database features.=20
Nowadays most relevant databases are pretty compatible when it comes to=20
constraints, so if you stick to the basics you should be fine now.

	UC

- --
Open Source Solutions 4U, LLC	2570 Fleetwood Drive
Phone:  +1 650 872 2425		San Bruno, CA 94066
Cell:   +1 650 302 2405		United States
Fax:    +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAhvgKjqGXBvRToM4RAmy1AJ9q2n44+9KFAp+o2u3NPqR6DISyGACePO6V
a6L/yfArAk3m0N6lSQVDx0k=3D
=3DdRNi
-----END PGP SIGNATURE-----