On Thu, Sep 25, 2008 at 3:52 PM, Andrew Sullivan <[EMAIL PROTECTED]>wrote:
> On Thu, Sep 25, 2008 at 01:13:29PM +0300, Asko Oja wrote: > > > > but why would you put part of your business logic into some configuration > > tables while you could keep it in your own functions > > Because the parameters of the business logic should not be in the > 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
