Thread: Re: generic modelling of data models; enforcing constraints dynamically...
Re: generic modelling of data models; enforcing constraints dynamically...
From
Oliver Kohll - Mailing Lists
Date:
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
www.gtwm.co.uk - company
www.gtportalbase.com - product
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 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
On Sun, Sep 27, 2009 at 5:44 PM, InterRob <rob.marjot@gmail.com> wrote: > 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? Actually that's what I think it's best at, as long as you aren't trying to get fancy. We have a part of an intranet type app that lets users upload table formatted data that's like a freeform spreadsheet and we use EAV to store the data for that. There's no FK or other relational stuff. The problems start to pile up when you try to do something exciting, interesting, fascinating or other 'ings...
Hi Rob, InterRob wrote: > 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... As I indicated in another mail. I use this exact same priciple. Have to agree if trying to write backend stuff, you running into troubles. Easier to manage through front-end application. If you want some more details, let me know, exactly what I am using for all my front-end applications. Regards, Johan Nel Pretoria, South Africa.