Re: [GENEAL] dynamically changing table

On Mar 31, 2009, at 6:41 PM, Harald Fuchs wrote:

> In article <437FAA9F-DF2D-429E-9856-EB2026B55940(at)solfertje(dot)student(dot)utwente(dot)nl
> >,
> Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> writes:
>
>> You could add the columns you're sure that you need and put the rest
>> in an XML field.
>
> <mantra>
> If you have a problem and want to solve it using XML, you have two
> problems.
> </mantra>

<mantra>
A mantra is never good argumentation, whether for or against.
</mantra>

I don't like mantras, they're like dogmas, they prevent people from
thinking. I consider them dangerous ;)

> Why serializing the rest of the data in an XML field? contrib/hstore
> seems to accomplish the same, without the XML overhead.

Although I'm no fan of XML, it does have it's benefits. In this case,
it's standardised (which means there are libraries for about every
language to deal with XML data), it can store and constrain type
information (although a bit limited IMO) about the data and there are
many tools for manipulating data contained in XML and those can
usually also be used at the application side of things.

contrib/hstore doesn't do these things for you, so it adds problems of
its own. The OP may run into problems with database layers in his
programming language of choice that can't deal with the specifics of
querying a hstore field for example. If type information in the data
is of importance, he'll have to explicitly cast the data (based on the
key field). If certain fields are constrained to certain value ranges,
he'll have to check those in his application.

It all depends on the requirements of the OP and how far he wants to
go with this, if hstore solves his problem, by all means, go with it.
In either case, using an XML field is a valid solution. Nobody said
it's a perfect one.

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.

!DSPAM:737,49d2554e129747441114695!