Re: Performance of subselects

From: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
To: Christian Schröder <cs(at)deriva(dot)de>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Performance of subselects
Date: 2009-03-09 11:13:47
Message-ID: 2f4958ff0903090413t71f76ef7la9f06b7dbbbeac3c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2009/3/9 Christian Schröder <cs(at)deriva(dot)de>:

>
> I understand why this is advisable; however, something inside me hates the
> idea to put this kind of database specific stuff inside an application. How
> about portability? Why does the application developer have to know about
> database internals? He knows sql, that should be sufficient.
> I have the (maybe naive) idea of a clear separation of database
> administration (including performance tuning) and application development.
> Is this idea completely wrong?
>

and it is a good idea, especially since you might want to consider
heterogeneous DB target. Personally , I put views in DB, and wrap it
in a nice LIB. That also means, that I can change things in one place.
Just make sure, that you have proper test harness around that sort of
LIB, and everything should be okay.
I've seen projects in the past, where authors were trying to make
queries work on mysql/psql - and that just doesn't fly with me.

--
GJ

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Raymond O'Donnell 2009-03-09 11:14:38 Re: commit/rollback in postgre 8.2
Previous Message Christian Schröder 2009-03-09 10:45:38 Re: Performance of subselects