From: | InterRob <rob(dot)marjot(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: generic modelling of data models; enforcing constraints dynamically... |
Date: | 2009-09-27 23:44:47 |
Message-ID: | 671e36b0909271644p3cae759y731e5f7d323cbfc3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Oliver,
Would you say it is not valid for proposition 2 (people wanting to be able
to quickly add (and remove?) attributes) because within the relational model
this can be done reasonably well?
If you think so, then I we do in fact agree on that... Still, however,
implementing this transparently (that is: back-end/server side; using VIEWs,
is the only way I can think of) is a major challenge. Implementing the use
of USER DEFINED additional fields within a certain application (front-end /
client side) is much more easy...
Rob
2009/9/27 Oliver Kohll - Mailing Lists <oliver(dot)lists(at)gtwm(dot)co(dot)uk>
>
> On 27 Sep 2009, at 21:10, InterRob <rob(dot)marjot(at)gmail(dot)com> wrote:
>
> Peter, may I invite you to privately share some more details on the system
> you are using and the design of it? Did you implement it using PostgreSQL?
> Looking forward to your reply.
> (And with respect to your previous message: whom are you actually referring
> to by the acronym "OPs"?)
>
>
> Or publicly? I for one would be interested hearing more. From situations
> I've come across, EAV seems to be proposed when either
> 1) attributes are very numerous and values very sparse
> 2) people want to be able to quickly add (and remove?) attributes
> My feeling is it's probably valid for 1, at least I haven't come across
> anything better, but not for 2.
>
> Regards
> Oliver
>
> www.gtwm.co.uk - company
> www.gtportalbase.com - product
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2009-09-27 23:57:56 | dump time increase by 1h with new kernel |
Previous Message | Nobuhiro Iwamatsu | 2009-09-27 23:37:14 | Re: getting PostgreSQL to run on superH-based machines |