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