From: Uwe C. Schroeder <uwe@oss4u.com>
To: Andrew Sullivan <ajs@crankycanuck.ca>
To: pgsql-general@postgresql.org
Subject: Re: Replication
Date: Wed, 21 Apr 2004 14:39:05 -0800
Message-ID: <200404211539.06102.uwe@oss4u.com> (raw)
In-Reply-To: <20040421172803.GA325@phlogiston.dyndns.org>
References: <CAC2F23E-92AC-11D8-B5ED-000A95DE2550@ifrance.com>
<40869207.8020509@Yahoo.com>
<20040421172803.GA325@phlogiston.dyndns.org>
-----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
their system were massive differences between databases. The scope they had
in mind didn't allow for whole database layers to be redundant just for the
sake of being able to talk to several database engines - ergo they wrote one
layer and omitted using vendor dependant database features.
Nowadays most relevant databases are pretty compatible when it comes to
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=
=dRNi
-----END PGP SIGNATURE-----
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: uwe@oss4u.com, ajs@crankycanuck.ca
Subject: Re: Replication
In-Reply-To: <200404211539.06102.uwe@oss4u.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox