From: | "Jean-Yves F(dot) Barbier" <12ukwn(at)gmail(dot)com> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Table-design for categories, suggestions needed |
Date: | 2010-08-07 15:40:50 |
Message-ID: | 20100807174050.17974280@anubis.defcon1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Le Sat, 7 Aug 2010 09:27:26 -0300,
Victor Hugo <vh(dot)clemente(at)gmail(dot)com> a écrit :
> Hi,
>
> Think that an error of modeling. Occur this way, where there are 5
> types of subcategory in the table, there could be another table
> containing the information category and subcategory. Got it?
>
> exemple:
>
> TABLE categories (id, name_category)
> TABLE subcategories (id, name_subcategory)
> TABLE components (id, name_component)
> TABLE category_subcategory (id_category references categories(id),
> id_subcategory references subcategories(id) )
As they are components one ref can be of different technologies, it depends
on the choosen notation but it would be more efficient to use a generic
notation such as 74144, instead of using specific notation: 74LS144,
74HC144, 74L144...
Thus, creating a new table for technologies and table 'component'
(remember: notation rules say to never use the plural) should be:
CREATE TABLE tech (
id SERIAL PRIMARY KEY,
name VARCHAR(128) NOT NULL CHECK(char_length(name)>5)
);
CREATE TABLE component (
id SERIAL PRIMARY KEY,
name VARCHAR(32) NOT NULL,
tech INTEGER REFERENCES tech(id) NOT NULL
);
--
Common sense is instinct, and enough of it is genius.
-- Josh Billings
From | Date | Subject | |
---|---|---|---|
Next Message | William Furnass | 2010-08-08 20:16:50 | Recursive queries for network traversal |
Previous Message | Lew | 2010-08-07 12:28:37 | Re: Table-design for categories, suggestions needed |