Re: EAV (Re: Object-relational impedence)
Date: Thu, 03 Apr 2008 02:05:48 GMT
Message-ID: <0YWIj.1648$Nc5.550_at_newssvr27.news.prodigy.net>
> EAV's don't need to store nulls. You just don't include that entry. If
> a given index engine is not null-friendly, then perhaps an EAV is
> better than a sparse table as far as performance.
>
>
>>
>> The idea of a sparse table is ugly because it involves nulls.
>> Nulls--especially those that indicate 'there shouldn't be a value
>> here'--should be avoided whenever possible. If you're interested, there
>> have been many discussions on cdt regarding nulls. If you can wade
>> through
>> the flames, you might even find some useful information.
>>
>> Data has an inherent structure.
>
> Sometimes its "inherent structure" does NOT fit static tables well.
> The real world is not always friendly to a given abstraction. And,
> although I am against "nulls" for strings, the concept of some kind of
> "empty" cell (zero length) is not necessarily a bad thing. (In some
> RDBMS, zero length and null are the same thing, in others they are
> not.)
>
I don't think you understand "inherent structure."
>> Stuffing everything into one table, whether
>> it be an EAV table or a sparse table imposes an alien structure on the
>> data,
>> introducing redundancy and complexity and usually reducing performance.
>> A
>> solution that has one table per widget type also imposes a structure on
>> the
>> data, one that inevitably introduces redundancy. The 'table-happy'
>> design
>> that I suggested earlier does not introduce redundancy and does not
>> require
>> nulls.
>
> Your solution does NOT reduce redundancy because the foreign key has
> to be repeated over and over again. And, empty cells don't
> necessarily reduce performance, per above. And, filling up table-space
> is ugly and not debugging-friendly. Fat table-spaces slow me down. I
> cannot speak for everybody's psychology and hand-eye-mouse-brain
> coordination, but it slows down MINE.
>
By most, foreign key references do not constitute redundancy. In direct image systems, foreign key references are problematic because updates must often physically cascade. But not all systems work that way. Some systems internally use pointers instead of duplicating what is referenced so that physical cascades are unnecessary. And don't kid yourself: empty cells necessarily reduce performance, they just may not reduce it noticably.
> I will respect your choice because the tradeoffs are all sticky either
> way. But, I do not agree with it, nor do I agree with your performance
> criticisms and redundancy claims. They appear incorrect.
>
> -T-
Received on Thu Apr 03 2008 - 04:05:48 CEST