> 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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
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
No comments:
Post a Comment