Re: What is this model technique called

Originally posted by Jarson
> What do you call the data modeling technique where you store
> attribute NAME
> & VALUE pairs, instead of just typical descriptive column names.
>
> An example of where I am using this is to capture contract terms
> within a
> database, knowing that terms are very dynamic will vary from contract
> to contract.
>
> ATTRIBUTE_TYPES
> - ATTRIBUTE_NAME (PK)
> - DATA_TYPE
> - ENTITY_TYPE
> - UNIT_OF_MEASURE
> - DESCRIPTION
>
> CONTRACT_TERMS
> - CONTRACT_ID (PK) (FK to another Contract table)
> - ATTRIBUTE_NAME (PK) (FK to ATTRIBUTE_TYPES)
> - VALUE
>
> The first table is a configuration table and would list all possible
> contract terms that are available, possibly feeding a list-box
> in a GUI.
> The second table is the actual table showing those terms, and
> their values,
> associated with each specific contract.
>
> I also added ENTITY_TYPE to the first table, indicating that
> this table
> could be used as a source for several other tables such as CONTACTS or
> SPECIFICATIONS tables. Examples may be 'CONTRACT_ID', or
> 'CONTACT_ID', or
> 'SPEC_ID'. The advantage is that any GUI front-end for administrative
> maintenance only has to deal with one table.
>
> What is this technique called?
>
> Jarson
How about "a nightmare"? Yes, you only need one screen to maintain the data, but for that you have vastly complicated the process of querying the data and enforcing business rules (e.g. foreign keys, check constraints, even value datatypes).

There are some extreme situations that call for this kind of super-flexible approach. I couldn't say whether yours is one of them.

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!" I believe I may even have done so myself (many years ago). Then with more experience they realise that all they are doing is replicating the database catalog, but rather poorly (no declarative constraints, etc.)

A company called "Lazy Software" markets a product that appears to be based on this "why bother defining a database, everything's a 'thing'" approach. They call the technique "The Associative Model of Data".

--
Posted via http://dbforums.com