Re: Modeling question...
Date: Tue, 21 Oct 2008 22:06:16 GMT
Message-ID: <snsLk.3030$%%2.630_at_edtnps82>
JOG wrote:
> On Sep 11, 6:29 pm, Volker Hetzer <firstname.lastn..._at_ieee.org> wrote:
>> JOG schrieb: >> [JOG hat gesnipped] >>> If one is changing trying to change the attributes that entities >>> possess, than one is necessarily altering the propositions that can be >>> stated about them. This necessitates a change in relation predicates, >>> which means it is absolutely a DDL issue. To think otherwise seems to >>> somewhat miss the point of the relational model. >> Bit late but I was on holiday... >> I am not trying to change the attributes that an entity possesses but >> I am allowing each business object or user object or whatever you may >> call it to contain an attribute collection. There are no changes in >> relation predicates since any attribute name is just contents, like >> its value. >> I think we are talking at cross purposes. >> >> I'm curious, what do you people do when a customer comes and says, >> "I want to store <thing> and I want to add, change and remove key >> value pairs and I want to name them freely.". >> Are you telling them that a database can't do it?
>
> I'm telling them, and you, that the relational model can't do it
> because it was designed to handle "formatted" propositions (sets of
> data with a high level of common predication). It is important to
> recognize that the EAV approach you are looking at just happens to use
> the RM as its physical layer, and that's it. It does not use the RM as
> a logical model, and you therefore lose all of its algebraic power.
> (Sure you keep the management system's transactional capabilities, but
> thats nothing to do with the RM).
>
> In fact, having abandonded it, you might as well use XML, OO or RDF
> databases and cut out the middle man. However, better imo to convince
> the client that designing a robust a priori conceptual model is worth
> doing, and that you can come and update it at appropriate intervals (I
> say this because currently the RM is the most solid framework we
> have).
>
> I do have sympathy, because the issue of handling semistructured and
> dynamic schema is simply an unsolved problem (as is how to handle
> missing data). Proposed "solutions" are all woeful (in fact completely
> retrograde, whisking us back to 1960's tech). As such, anything you
> try and implement for your client will inevitably be an ad-hoc hack /
> in some way or other/. We're still in the stone age of informatics i'm
> afraid. Regards, Jim.
> ...
I remember more than thirty years ago when companies sent some of their mid-level non-DP types to report writer school, sponsored by various outfits who're gone now or absorbed by bigger ones. A few of those people got good enough to submit their own queries in the batch mode of the day and only resorted to the DP department (wasn't called IT then) when it was over their head. They were hip enough to know when they were over their heads and didn't waste time like some of us (including me). Of course the majority were useless at this, as I think they were in their official function (this being typical of most commercial pursuits, if you ask me).
Makes me wonder why commercial enterprises that are laying off IT people don't try some minimal training for their middle muddler people in relational algebra. If they did, I guess they'd have to put in some fairly strict rules for their dba's.
Is it naive to think that some end-users could add attributes (ignoring the problem that this would make them non-end-users)? Received on Wed Oct 22 2008 - 00:06:16 CEST