Re: EAV - again

From: Erwin <e.smout_at_myonline.be>
Date: Mon, 9 Feb 2015 11:05:08 -0800 (PST)
Message-ID: <10d4ab2f-c4bc-4580-bd20-91b319845985_at_googlegroups.com>


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. Received on Mon Feb 09 2015 - 20:05:08 CET

Original text of this message