David Johnston wrote
> cars-properties
Note that typically "properties" of an object/entity are modeled as
attributes/columns on the entity table.
cars [ carid serial, car_make text, car_model text, car_year text]
as opposed to separate tables. That main reason for this is that each
property has a specific data type to which correct values must conform. A
generic "cars-properties" table would require that all property values be
stored as text.
Note that it is also valid to define cars like:
cars [ carid serial, car_properties hstore|json ]
so that the properties are a simple key-value table. A combination of both
can work as well.
This is where "Database Design" comes into play and as mentioned many
excellent books exist on the topic. Once you have a design you then develop
whatever UI elements that are needed to properly interact with it. While UI
is most important there is ample room for layering and facade-ing that
settling for a known sub-optimal database design will likely be painful in
the long-run.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/understand-basics-multiple-cars-in-a-database-selection-of-one-tp5790571p5790597.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.
