Re: What is this model technique called

>The EAV idea seems to be under active
>discussion at the moment

:) I was the unsuspecting idiot who fell squarely into this hot debate. Now I am left with the onerous task of salvaging whatever is left ...

> "I think every database designer/developer goes through a stage where
> they think 'Hey, I can generalize this down to 2-3 tables: entities,
> attributes and (maybe) relationships. What a super-flexible solution!'"

Too true. I read it too and instantly laughed - I have witnessed quite a few designs like this recently. But these have been designs off-the-bat ie. they designed EVERYTHING like this from the start. With such designs, the devil waits at two places: at development time and, far more insidiously, at production time when db performance of the industrial-strength RDBMS amounts to nought! I don't advocate this at all.

> He then points out that those of us who have tried it realize we must go
> piece by piece through the DB Server and re-implement every single
feature,
> since the system is meant to work on predefined columns inside of tables.

Yes.

> It is much simpler, easier, and effective to have a set of tools that lets
> you rapidly react to design changes.

Yes, again. Although I would never recommend the E+AV approach as a first choice - I do believe there are times when you cannot assume what and how many attributes will be required for some entities/tables for the final implementation of a system.

Example: in a small document management system I built recently, I had to create a subsytem (code+tables) that would allow for different customers of mine to capture different indexing information relating to their documents. One client may want to capture ID Numbers (social security numbers), others would want to capture claim numbers etc. I cater for a limited amount - say 10 - of such "index" fields [oops, attributes :)] by means of proper columns. Then for what could be dozens more for a particular client, I would make use of the Attribute-Value structure.

The strategy being: use it for modelling exceptions. Not a default design principle from start for *all* tables and attributes.

Regards

Abdullah Received on Sun Jun 08 2003 - 18:35:38 CEST