Re: EAV - again
Date: Mon, 9 Feb 2015 21:14:34 +0000
Message-ID: <slrnmdi8pq.qel.eric_at_bruno.deptj.eu>
On 2015-02-09, Erwin <e.smout_at_myonline.be> 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
>
> The "right" way to do 1) is through dynamic DDL.
>
> The end-user creating the "end-user entity" leads to a CREATE TABLE.
> The end-user adding a new attribute to his "end-user entity" leads to
> an ALTER TABLE. Screens displaying the information in this user-table
> get the meta-information they need by reading the catalog. Ditto for
> screens/programs editing the information. Protection against injection
> may be a major concern here. The security system must facilitate
> end-users being granted DBA privileges (which is logical because that's
> the job they're doing anyway), possibly in a selective fashion.
> But the advantage is that any user with access to this database can
> then use any regular SQL tool (reporting, DWH extraction suites, ...) to
> access the end-user tables just like any of the other ones.
That probably is the right way.
Eric
-- ms fnd in a lbryReceived on Mon Feb 09 2015 - 22:14:34 CET