Re: Modelling objects with variable number of properties in an RDBMS
Date: Wed, 2 Nov 2005 15:04:26 -0000
Message-ID: <e-Sdndl8GKQgSPXenZ2dnUVZ8qednZ2d_at_pipex.net>
"vc" <boston103_at_hotmail.com> wrote in message
news:1130939293.784399.319040_at_g43g2000cwa.googlegroups.com...
>
> I gave you a reason why someone might be forced into using EAV to which
> you gave a smart-alecky response.
I had intended it to be a mildly witty way of expressing an important point. I didn't realize it might seem to lack proper gravity.
> That was tried and rejected primarily for performance reasons. The EAV
> approach turned out to be faster and various SQL queries turned out to
> be simpler in comparison to trying to combine results from multiple
> tables representing a single entity.
We weren't discussing performance, but I'll let that pass.
I find both claims quite astonishing. That is entirely contrary to what I would expect. Evidently it was contrary to what they expected too since you say they tried one of my suggestions. Since it seems we agree that wasn't the expected outcome that makes it an extraordinary claim.
An extraordinary claim always requires extraordinary proof and I think it is quite reasonable for me to remain skeptical about this until the evidence makes it perverse of me to go on denying it. I can be persuaded by evidence. Can you provide full details? Since it was unexpected, I would need to be convinced that no ordinary explanation could account for why the EAV design was (a) faster, and (b) "various SQL queries turned out to be simpler". Examples of the latter would be extremely compelling.
I am not clear if it it is your opinion that the EAV design is beneficial in general. Is that the claim you you make, or are you just saying that in this one time and place it worked better than several other things they tried?
> There is a burden on you because you did not offer a sensible
> alternative after having rejected EAV in toto.
That is not the way rational discourse proceeds. The burden is never on the party that takes the established position (that's what established means).
The EAV design has been widely and repeatedly criticised, has numerous clear weaknesses with respect to the established approach, and there are plausible reasons to doubt it should be intrinsically easier to code for. It is contrary to the established position. There is no burden on me to defend the established position.
Roy Received on Wed Nov 02 2005 - 16:04:26 CET