On Thu, Sep 25, 2008 at 3:52 PM, Andrew Sullivan <ajs@commandprompt.com> wrote:
Well by configuration tables i meant some oracle/postgresql system tables.
We also have parameters of business logic in configuration database that is replicated into each oltp database that needs them and they are updated by dba's during normal release process. Althou this part is managed by DBA's the changes themselves are prepared by developers. So i see no PostgreSQL ability to work that way. What i see is lack of useless bells and whistles in PostgreSQL and i like it.
regards,
Asko
On Thu, Sep 25, 2008 at 01:13:29PM +0300, Asko Oja wrote:Because the parameters of the business logic should not be in the
>
> but why would you put part of your business logic into some configuration
> tables while you could keep it in your own functions
code. The parameters should be part of the configuration, to be
administered by the administrators (i.e. the DBAs) and not by the
database developers. In traditional large database shops, that is the
division of responsibility, and the inability to work in that way will
hamper Postgres adoption in that environment. (Maybe we don't care,
but let's at least be honest that changing the culture of such
database shops is not something we're going to achieve quickly.)
Well by configuration tables i meant some oracle/postgresql system tables.
We also have parameters of business logic in configuration database that is replicated into each oltp database that needs them and they are updated by dba's during normal release process. Althou this part is managed by DBA's the changes themselves are prepared by developers. So i see no PostgreSQL ability to work that way. What i see is lack of useless bells and whistles in PostgreSQL and i like it.
regards,
Asko
No comments:
Post a Comment