Re: What is this model technique called

Quoting unnamed sources, Abdullah Kauchali claimed:

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

:) I have actually found it illuminating and helpful. Some months ago the EAV thing took root in the mind of somebody who tried to hire me to implement it. He was convinced he had thought of it himself and that nobody else ever had. The politics of the situation meant I could not simply dismiss it, I had to take it apart piece by piece with him. He gave me the very strong impression he did not believe me and I simply was not trying hard enough, but it is good to come here and see that others have come to the same conclusion, that my judgement and experience are not unique.

<snip various points of agreement>
>

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

Agreed as well.

>
> 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.

One good example deserves another. We are spending the next 12 months building a generalized table-driven task handler. Many of our clients have active feeds in and out of the system, so we have a dozen or so common tasks to perform, and we want them stored as data instead of code. Problem is, we know that we cannot predict every type of task we will write a handler for, and so we cannot predict the shape of the tables to start.

So we created two tables that are fixed well enough that are used to describe tasks, and then a spill-over EAV table that we will use to store attributes we did not plan well enough for at this stage. The idea is to allow the programmer freedom to easily experiment with adding support for attributes before committing to a concrete design that would be better supported with a real column.

Hmmmm, perhaps that is the dividing line we have been looking for, prototyping? A programmer can build in crude support for some attributes and feel his way through where they should go. Then when he is comfortable, he can commit them to being columns in a table. Some would say this smacks of bad practice, in that you are supposed to plan much better than that, but this humble developer finds proper designs are a lot easier to discover if you actually make up a lot of example designs and start watching how they behave, so I will happily defend "bad practice" during the prototyping stage.

>
> Regards
>
> Abdullah

-- 
Kenneth Downs