Re: EAV - again

On 2015-02-07, James K. Lowden <jklowden_at_speakeasy.net> wrote:
> 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.

In 1 the developer(s) provide something for others to use, in 2 they are providing something for themselves to use, but yes, there is a lot of overlap.

>> 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.

Perhaps the term should be "non-data", and I am thinking of a picture, or a poem, or a newspaper article which, these days, are stored in a computer system. Of course there will be meta-data for them which, from out point of view, is data and should be properly structured. But how do we say, in our system, that a picture is linked to a poem because it is claimed to be the inspiration for the poem. This pretty much has to be a generic link because you can't predict what link descriptions people will want, so a schema handling this is going to look like EAV, isn't it?

>> * 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?

There are organisations like that, and you can't win (in any sense) at the level we are at here.

> 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.

Yes, but even in an organisation trying do do it properly, and with someone in charge of logical design who was both competent and reasonable, I have seen a case of 2 - maybe it was just out of habit, but still...

Eric

-- 
ms fnd in a lbry