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)
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 |
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 |