Re: EAV - again

On Thu, 5 Feb 2015 21:50:34 +0000
Eric <eric_at_deptj.eu> wrote:

> 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

Those two are the same, or nearly. They're both ways to add to the schema without making the addition explicit.

> 3 as a way of recording relationships between unstructured pieces of
> data

Boy, do I dislike that term. Data are signal amid noise. Structure is its distinguishing feature. Unstructured data don't exist.

Acknowledged, "unstructured" is the term people use for "data not organized as tables". It's evidence of the influence of the relational model on our thinking and assumptions. Even Stonebraker refers to "semi-structured" data, knowing full well there's no halfway point between structured and not. I imagine he uses it because it conveys an idea.

I think what he means is really unanalyzed or poorly organized data. I think that's a better term because it puts the emphaisis where it belongs: not on the "nature" of the data, but on the undone work of preparing them for analysis.

> * what is the right way to do 1?
> * how do you argue against 2 (and win)?

You cannot reason a man out of a position he did not reason himself into.

Every organization I know of has policies that thwart the use of database management systems. Administrative access is so tightly controlled that often the DBAs themselves are required to acquire temporary authority to do their jobs, and justify why. No one is in charge of the logical design. Changes are never measured against correctness or coherency, but by whether or not "anything breaks", a question the organization devotes precious little resources to make possible to answer a priori. Stupidity predictably breeds conservatism, and the hairball only grows.

The organizational structure, by actively preventing use of the management features in the DBMS, layers cost upon cost: controlling the administrators instead of requiring them to control (and exploit) the system. In such an Alice-in-Wonderland world, what does "win" mean?

The right way to do it is to make the features of the DBMS accessible to the application and the user in controlled ways. Most DBMSs today support namespaces of some kind, e.g. "roles", that permit database objects that are seen only by a particular group. Let users and applications define tables according to their "needs" as they see them. Surely there's no more harm in that than in providing only an EAV and foreclosing any opportunity for database management.

--jkl Received on Sat Feb 07 2015 - 20:44:39 CET