Re: What so special about PostgreSQL and other RDBMS?

Guys, Guys....
Calm down.
The propositions put forth by Quirk are becoming lost in a tide of acrimony.

Proposition 1:
There are circumstances under which my client is better protected against commercial or accidental events, if he possesses source code to the application and the underlying database management system.

I agree with that proposition.

Proposition 2:
There are circumstances under which my client is better protected against commercial or accidental events, if I have coded my application in such a way (by use of a database abstraction layer) that migrating my application to a different database management system is made very easy.

I agree with that proposition.

Proposition 3:
There are circumstances under which my client is better protected against commercial or accidental events, if he has a human readable backup of the database of the type Quirk describes.

I agree with that proposition.

Note that neither Quirk nor I claim that these propositions always apply to every situation, nor that there are not clear and obvious exceptions.

However, I must take issue with Noons, who states:

> But, my dear cyber-friend: no vendor of anything considered
> base-layer software like databases has EVER changed the product
> so much that it broke all previous code! That would be called
> "suicide" in market terms. It's never happened, it will never happen!
> There is NO NEED to work around such an eventuality: it won't happen,
> it's a wasted effort.

There are large companies in our industry who are famous for implementing backward-incompatibility in new versions of their software. Further, most support is time limited: once the software has reached a certain age, the vendor demands that you upgrade (at your cost) if you want to continue to receive support and bug fixes. Clearly, that makes good commercial sense and nobody would dispute their right to drop suport for old products, but it does lock customers into an "upgrade or else" cost cycle. If a customer decides not to upgrade, the vendor has effectively broken the code for the customer as soon as the next bug or insecurity is encountered: no support means no fix.

The point here is that current commercial practice by many vendors forces clients into expensive upgrades which have no direct commercial benefit to the customer. Quirk's propositions present a scenario under which customers have the freedom to choose what to upgrade and how much to spend, based on their own business imperatives and not those of a third party on which they depend.

After 25 years in the industry, I know of many organisations which are getting heartily sick of spending vast sums of money in knee-jerk upgrades (which usually involves staff retraining and other ancilliary expenses) at the whim of a vendor. When I am able to offer my customers an alternative to this revenue drain, I am happy to do so. It is not always possible or appropriate, but when it is, the benefits are exactly as Quirk has laid out.

Your mileage may vary.

Kind regards,
Doug Hutcheson

--
Remove the blots from my address to reply