Re: EAV - again

From: Erwin <e.smout_at_myonline.be>
Date: Sat, 7 Feb 2015 08:05:33 -0800 (PST)
Message-ID: <3ea1f976-1e9c-42ef-9f01-e902ed3a3567_at_googlegroups.com>


Op vrijdag 6 februari 2015 22:10:04 UTC+1 schreef Eric:
> On 2015-02-06, Erwin <> wrote:
> > Op donderdag 5 februari 2015 22:50:44 UTC+1 schreef Eric:
> >> We are used to hearing about EAV as a superficially clever idea which is
> >> actually very bad. Not arguing with that at all. How might one look at
> >> EAV?
> >>
> >> 1 as a way of providing end-user tailoring
> >>
> >> 2 as a way of adding entities and attributes without needing a database
> >> Change Control
> >>
> >> 3 as a way of recording relationships between unstructured pieces of
> >> data - http://geek-and-poke.com/?offset=1375995832310 (the data model
> >> one) may be about this really
> >>
> >> So,
> >>
> >> * what is the right way to do 1?
> >>
> >> * how do you argue against 2 (and win)?
> >>
> >> * is 3 a legitimate need?
> >>
> >> Eric
> >> --
> >> ms fnd in a lbry
> >
> > What is your perceived difference between (1) and (2) ?.
>
> 1 is software designed around EAV as a way of providing end-user
> tailoring.
>
> 2 is developers trying to dodge the red tape they are supposed to work
> with
>
> Eric
> --
> ms fnd in a lbry

That's cryptic.

EAV is typically and mostly used as a way to shove off the database design work onto the end user. I see that description fitting both your (1) and (2). Fitting with (1) because it provides a means for the end user to tailor the information model of this application. Fitting with (2) because, well, [that kind of] tailoring the information model is nothing else than "adding extra entities without database change control". Received on Sat Feb 07 2015 - 17:05:33 CET

Original text of this message