Re: Database design?
От | Rich Shepard |
---|---|
Тема | Re: Database design? |
Дата | |
Msg-id | Pine.LNX.4.33.0110230640160.28228-100000@salmo.appl-ecosys.com обсуждение исходный текст |
Ответ на | Database design? ("Johnny Jørgensen" <johnny@halfahead.dk>) |
Ответы |
Re: Database design?
|
Список | pgsql-general |
On Tue, 23 Oct 2001, [ISO-8859-1] "Johnny J�rgensen" wrote: > This relation is of a 1-N nature for each entity, and so, i've figured > out, I use the unique id from the (book, e-book, author etc) tables as a > foreign key in the description table, thus forging a relation. > > The question (at last) is, how to have a foreign key reference more than > one table? Obviously a description won't belong to an e-book, a country > and a publisher at the same time, but only one of them. 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
В списке pgsql-general по дате отправления: