Re: Database design? - Mailing list pgsql-general
From | Aasmund Midttun Godal |
---|---|
Subject | Re: Database design? |
Date | |
Msg-id | 20011023162643.24521.qmail@ns.krot.org Whole thread Raw |
In response to | Re: Database design? (Rich Shepard <rshepard@appl-ecosys.com>) |
Responses |
Re: Database design?
|
List | pgsql-general |
Ok let me try to explain how I would do it: CREATE TABLE languages ( "language" TEXT PRIMARY KEY, ); CREATE SEQUENCE description_seq; CREATE TABLE descriptions ( id PRIMARY KEY, -- You could make this default -- curval('description_seq') -- if you are absolutely 100% sure only one person inserts at the time. description TEXT NOT NULL, language REFERENCES languages NOT NULL, UNIQUE(id, language) ); CREATE TABLE authors ( id DEFAULT nextval('decription_seq') PRIMARY KEY, firstname TEXT, lastname TEXT NOT NULL, unique(firstname, lastname) ); CREATE TABLE books ( id DEFAULT nextval('decription_seq') PRIMARY KEY, title, author REFERENCES authors NOT NULL, book bytea, unique(title, author) ); This is the basic structure. Now if you like you can have a map table - although I am not sure I would. CREATE TABLE languages ( "language" TEXT PRIMARY KEY, ); CREATE SEQUENCE description_seq; CREATE TABLE map ( id DEFAULT nextval('decription_seq') PRIMARY KEY ); CREATE TABLE descriptions ( id REFERENCES entities PRIMARY KEY, -- You could make this default -- curval('description_seq') -- if you are absolutely 100% sure only one person inserts at the time. description TEXT NOT NULL, language REFERENCES languages NOT NULL, UNIQUE(id, language) ); CREATE TABLE authors ( id REFERENCES entities PRIMARY KEY, firstname TEXT, lastname TEXT NOT NULL, unique(firstname, lastname) ); CREATE TABLE books ( id REFERENCES entities PRIMARY KEY, title, author REFERENCES authors NOT NULL, book bytea, unique(title, author) ); On Tue, 23 Oct 2001 06:47:30 -0700 (PDT), Rich Shepard <rshepard@appl-ecosys.com> wrote: > On Tue, 23 Oct 2001, [ISO-8859-1] "Johnny Jørgensen" wrote: > > > If I understand your situation correctly, you may want to have an > intermediate table that provides a M-M (many-to-many) link. > > It's still early enough here that I won't try to describe the solution for > your tables, but I'll give you an example. In the accounting software I've > developed, there's a need to track project billing rates by employee (or > employee class). These rates may vary from one project to another project. > What I've done is have a table with a compound primary key: employee_id*, > project_id*, rate. > > You might have unique_id*, item_type*, language*, description. Here, your > table has a compound key of three fields, each of which is the primary key > to another relation. The 'description' field is then uniquely applied to one > -- and only one -- combination of the three key fields. > > HTH, > > Rich > > Dr. Richard B. Shepard, President > > Applied Ecosystem Services, Inc. (TM) > 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. > + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com > http://www.appl-ecosys.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly Aasmund Midttun Godal aasmund@godal.com - http://www.godal.com/ +47 40 45 20 46
pgsql-general by date: