Thanks for the help, and for different design options it really helped me. I
had
a look on vertical design and horizontal design and this is some cons and pros
in general for vertical design
Advantages:
•Avoid null values and utilize storage
•Avoid constant schema changes due to
Hello,
suppose the following scenario
the car speed is 240
the car has an airbag
Here the first value is integer and the second value is boolean. Consider that
I
have this table structure
feature (feature id feature name)
car (car id, )
car_feature (car id, feature id, value). the
On 07/26/11 10:02 AM, salah jubeh wrote:
and using ANSI compliant design
American National Standards Institute? they have an ANSI standard on
database schema design or something?
--
john r pierceN 37, W 122
santa cruz ca mid-left coast
To: pgsql-general@postgresql.org
Sent: Tue, July 26, 2011 7:10:47 PM
Subject: Re: [GENERAL] variant column type
On 07/26/11 10:02 AM, salah jubeh wrote:
and using ANSI compliant design
American National Standards Institute? they have an ANSI standard on database
schema design or something
On Jul 26, 2011, at 10:02 AM, salah jubeh wrote:
Hello,
suppose the following scenario
the car speed is 240
the car has an airbag
Here the first value is integer and the second value is boolean. Consider
that I have this table structure
feature (feature id feature name)
car
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
the car speed is 240
the car has an airbag
Here the first value is integer and the second value is boolean. Consider
that I have this table structure
feature (feature id feature name)
car (car id, )
car_feature (car id, feature id, value). the value attribute might have
salah jubeh, 26.07.2011 19:02:
Hello,
suppose the following scenario
the car speed is 240
the car has an airbag
Here the first value is integer and the second value is boolean. Consider that
I have this table structure
feature (feature id feature name)
car (car id, )
car_feature (car
On Tue, Jul 26, 2011 at 11:06 AM, David Johnston pol...@yahoo.com wrote:
Given “feature” and “car-feature” tables the presence of absence of an entry
in “car-feature” will accomplish your desire for true/false - i.e., “the car
has an airbag”. By abstracting just a little every “feature” can
-Original Message-
From: Chris Travers [mailto:chris.trav...@gmail.com]
Sent: Tuesday, July 26, 2011 2:32 PM
To: David Johnston
Cc: salah jubeh; pgsql
Subject: Re: [GENERAL] variant column type
In your example you could create a feature called Top Speed 240kph
If every car is going
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
11 matches
Mail list logo
