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@xxxxxxxxxx>
On 27 Sep 2009, at 21:10, InterRob <rob.marjot@xxxxxxxxx> 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 either1) attributes are very numerous and values very sparse2) people want to be able to quickly add (and remove?) attributesMy feeling is it's probably valid for 1, at least I haven't come across anything better, but not for 2.RegardsOliver
