Re: generic modelling of data models; enforcing constraints dynamically... - Mailing list pgsql-general

From InterRob
Subject Re: generic modelling of data models; enforcing constraints dynamically...
Date
Msg-id 671e36b0909271644p3cae759y731e5f7d323cbfc3@mail.gmail.com
Whole thread Raw
In response to Re: generic modelling of data models; enforcing constraints dynamically...  (Oliver Kohll - Mailing Lists <oliver.lists@gtwm.co.uk>)
Responses Re: generic modelling of data models; enforcing constraints dynamically...  (Scott Marlowe <scott.marlowe@gmail.com>)
Re: generic modelling of data models; enforcing constraints dynamically...  (Johan Nel <johan.nel@xsinet.co.za>)
List 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.lists@gtwm.co.uk>

On 27 Sep 2009, at 21:10, InterRob <rob.marjot@gmail.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

pgsql-general by date:

Previous
From: Sam Mason
Date:
Subject: Re: PostgreSQL reads each 8k block - no larger blocks are used - even on sequential scans
Next
From: Justin Pryzby
Date:
Subject: dump time increase by 1h with new kernel