Re: Generalised approach to storing address details

From: Neo <neo55592_at_hotmail.com>
Date: 11 Dec 2006 11:24:07 -0800
Message-ID: <1165865047.213790.41690_at_n67g2000cwd.googlegroups.com>


> > > Debate was about EAV and the idea of storing several type of
> > > information in the same tables. I have provided an example about it .
> > > Bringing hierarchies does not add or substract anything to the debate.
> >
> > EAVs and hierarchies share the same characteristics in that neither
> > follows IP. This is why RM can't manage either very well. If you feel
> > it does, please replicated the recent example in thread titled
> > "Bi-Directional Transitive Closure (with dbd)".
>
> You think that Hierarchies and EAV are alike problems?

With respect to them both violating the implied intent of the Information Principle, yes.

> You think that because they would (and they certainly don't) share the same
> characteristics, you can conclude anything from it with the incoherence
> you have demonstrated so far?

Both your solution to the hierarchal problem and my suggestion of an EAV solution to OP's problem share the characteristic that we encoded implied information between attributes/values which is not expressed by relation's tuple's attribute's values. For a more detail explanation, see earlier response to JOG's "First show me some indication that you understand that the EAV approach does not use RM as the logical model".

> You think that RM can't handle hierachies after I answered your demand on the *Brothers and Sisters* thread with a simple structure that perfectly met your criterias?

It is not that RM can't handle hierarchies, however they are generally implemented in an unsystematic manner that violates the implied intent of the Information Principle. By the way, if you actually try to execute any of queries that you have posted for the "Brothers and Sisters" example, you will find that none of them work. Regardless, please give the "Bi-Directional Transitive Closure" example a try. Received on Mon Dec 11 2006 - 20:24:07 CET

Original text of this message