Raphael Bauduin wrote:
> That was our first choice design, but we really need that extreme
> flexibility with the details.
> Item details specs are a moving target, with impossibility to prevent
> changes.... Items are also very different, but if we had to have one
> table per item, it would be unmanageable. New items types are regularly
> created too, which would ask the creation of new tables.
> About the different types we could have to store as details: we have a
> table with date details.
>
> I'm also very cautious with that design, and am aware of the risks in
> it, but we have thought about it a long time, and it seems to be the
> best in our situation.
> We are in the final stage in this DB design and all tests until now have
> been positive.
See contrib/tablefunc, and read through the following link for examples
similar to what you are doing:
http://www.joeconway.com/pres_oscon_2004-r1.pdf
http://www.joeconway.com/flex.sql
HTH,
Joe