Re: EAV - again
From: Eric <eric_at_deptj.eu>
Date: Sun, 8 Feb 2015 12:49:46 +0000
Message-ID: <slrnmdemra.796.eric_at_bruno.deptj.eu>
>> 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
Date: Sun, 8 Feb 2015 12:49:46 +0000
Message-ID: <slrnmdemra.796.eric_at_bruno.deptj.eu>
On 2015-02-07, Erwin <e.smout_at_myonline.be> wrote:
> 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".
Fits 2 up to a point, but it is more "make my life easier" or "hey user, I think I can short-circuit this to get it in production sooner".
Eric
-- ms fnd in a lbryReceived on Sun Feb 08 2015 - 13:49:46 CET