Re: more anti-postgresql FUD

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Tim Tassonis <timtas(at)cubic(dot)ch>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: more anti-postgresql FUD
Date: 2006-10-12 20:22:56
Message-ID: 20061012202256.GY28647@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Oct 12, 2006 at 07:40:42PM +0200, Tim Tassonis wrote:
> > I have yet to see a good application that supports "database
> independence".
>
> If you are talking about high- end applications (big databases with lot
> of transactions), you're of course right. However, there are a lot of
> applications with small or medium sized databases and not so many
> transactions, where you don't need to get the best out of your RDBMS for
> decent performance.
>
> With a good design and some expierience in portability in general, you
> will be able to write a good, "quite" database independent application,
> supporting some of more standardized RDBMS's.

Actually, back when I worked at http://ud.com we had a fairly complex
database that could see a heavy transactional load and was actually
quite database independent (we developed on DB2, supported Oracle, could
have supported MSSQL and at one point actually had it running on
PostgreSQL). The application made extensive use of functions/stored
procedures, constraints, RI, and triggers.

How did this miracle occur? Well... the database code itself wasn't
actually database independent. It was generated by a bunch of XSLT that
we developed (we called it 'datadef'). In addition to generating
database generation code (SQL), it generated C accessor functions (much
of the code was in C), documentation, and some other things.

In fact, it even had the ability to generate code in a language it could
understand. This allowed us to do enums in such a way that the C code
had a real enum type, and the database had a table that stored the same
information. You could then refer to that enum anywhere in a table
definition in datadef, and an appropriate field definition would be
created, complete with RI back to the appropriate parent table.

Sadly, my understanding is that management didn't want datadef
open-sourced.

But you can actually write good code that will run on multiple
databases if you're willing to write the tools to allow you to do it.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2006-10-12 20:31:50 A query planner that learns
Previous Message Wei Weng 2006-10-12 20:22:14 Re: Question on MD5 authentication

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2006-10-12 20:28:41 Re: array_accum aggregate
Previous Message David Fetter 2006-10-12 19:48:25 Re: create temp table .. on commit delete rows