Re: Modeling question...

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.

> That whatever the
> reason, it's stupid? That no more than 255-minus-housekeeping
> attributes are allowed because, say, oracle can't do more columns?
> That no attributes can contain more than 22 or whatever characters?
> What do you say when they ask the some intern and he comes up
> with a <thing_id>,<attribute_name>,<attribute_value> table attached
> to the <thing> table by a one-to-many relation and tell you this
> is what they want?
>
> Lots of Greetings!
> Volker
>
> --
> For email replies, please substitute the obvious.
Received on Tue Oct 21 2008 - 23:31:47 CEST