On Tue, 26 Jul 2011 10:45:27 -0700, John R Pierce wrote:
> in general, attribute-value sorts of lists are very difficult to use
> for relational operations and result in clumsy inefficient queries,
> as
> well as poor data integrity.
>
> whenever possible common attributes shoudl be stored properly as
> table fields. reserve EAV for highly sparse freeform information
> that could not have been anticipated at design time. for your
> example, all cars have a speed, and do/don't have an airbag, so these
> should be normal fields in a table.
>
>
> --
> john r pierce N 37, W 122
> santa cruz ca mid-left coast
Everything above is true and.
Database table is like C struct, no inheritance. If you have common
attributes per some class, but no all cars have same class, you may
create "extending" table with those attributes as columns, and then join
it with car.
Currently I work on project with design car 1..* features. It's
painful. Many features id's hard-coded, no contract programming (no
support from compiler, etc. I use O-R libraries, and I can't even write
car.speed!
Regards,
Radek