Re: more anti-postgresql FUD

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: more anti-postgresql FUD
Дата
Msg-id 20061012202256.GY28647@nasby.net
обсуждение исходный текст
Ответ на Re: more anti-postgresql FUD  (Tim Tassonis <timtas@cubic.ch>)
Список pgsql-general
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@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

В списке pgsql-general по дате отправления:

Предыдущее
От: Tony Caduto
Дата:
Сообщение: Re: Error handling inside PL/pgSQL functions
Следующее
От: Scott Marlowe
Дата:
Сообщение: A query planner that learns