Re: variant column type

 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