Re: Attribute-values in separate table

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Tue, 30 Oct 2007 11:27:12 GMT
Message-ID: <kyEVi.6828$CN4.1647@news-server.bigpond.net.au>

DBMS_Plumber wrote:
> On Oct 26, 5:19 pm, -CELKO- <jcelko..._at_earthlink.net> wrote:

>> Every few months a Newbie re-invented the EAV fallacy and thinks they
>> are so clever.  A really good horror story about this kind of disaster
>> is at:
>>
>> http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/

[..]
> But it's almost always an utter disaster. Once the data is in the
> application, it's impossible to get it out again without writing a
> small-fridge sized (bigger than a bread-box, smaller than a washing-
> machine) chunk of code. And even if you can, the data integrity is
> typically shot. So you really can't migrate to any kind of replacement
> system.
>

[..]
>
> Now, when I visit a site or get on a conference call with an unhappy
> project, two of the first questions I ask are "How many tables do you
> have?" and "How many columns in your widest table?". If either of
> those answers was less than 10, I would kinda triage the whole project
> and write it off as unpossible to fix.

Forgive me for I have sinned!

<Confession>
I have (once only) deployed an EAV solution - as a very isolated interface to an ETL gizmo (ie. not actually a "system") where they couldn't define all the requirements but knew when it had to be finished. The dynamism they needed in the schema would not have survived the (production) change control process and still met the drop dead date so a special case was "approved". </Confession>

In mitigation it is not self referencing like the "best" examples seen in this thread...so it is quite plain in comparison.

The monster is still in place but a pig on space and performance albeit it only has to perform once a month. I have my .303 sight firmly trained on it and in the near term it will cop a slug right between the eyes!

Cheers, Frank. Received on Tue Oct 30 2007 - 06:27:12 CDT