On Sun, Sep 21, 2008 at 10:49:56PM +0400, Dmitry Koterov wrote: > Normalization is not a panacea here. Sometimes such normalization > creates too much overeat and a lot of additional code (especially if > there are a lot of such dependencies). Array support in Postgres is > quite handy; in my practive, moving from a_b_map to arrays > economizes hundreds of lines of stored procedure and calling > application code.
There are plenty of ways to "economize," as you put it. The burden is on you to demonstrate that you are doing the right thing here because standard database practice hammered out over decades is to normalize. It's possible to make writeable VIEWs that accomplish what you appear to want, but there's no reason to go further than that on the PostgreSQL side. :) > Triggers are not very helpful here, because it is too boringly to > control that all needed tables has appropriate triggers (we need N + > 1 triggers with unique code, where N is the number of referring > tables). > > So, built-in support looks much more interesting... I strongly suspect you'd benefit a lot more by learning database best practices rather than assuming, as you appear to be doing, that you are dealing with a new field and that you know it best. Neither is true. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
