Re: What is this model technique called
From: Kim <kim_at_geoknowledge.com>
Date: Fri, 06 Jun 2003 13:49:24 +0200
Message-ID: <3ee07ecd$1_at_news.broadpark.no>
>>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
Date: Fri, 06 Jun 2003 13:49:24 +0200
Message-ID: <3ee07ecd$1_at_news.broadpark.no>
andrewst wrote:
> 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
I'm working on a project where we use kind of a mix of the two approaches. Personally I think entity-attribute-value approach smells bad, so I try to promote modeling the database as close to the object models as possible. So I'm interested in some good arguments or reference to literature discussing the two approaches. Any ideas?? Received on Fri Jun 06 2003 - 13:49:24 CEST