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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
