Re: [ADMIN] Urgent - SQL Unique constraint error (long)
От | Darrin Domoney |
---|---|
Тема | Re: [ADMIN] Urgent - SQL Unique constraint error (long) |
Дата | |
Msg-id | FEEFJMJKKPINIKCCCCBJIEFHCAAA.ddomoney@emergingfrontiers.ca обсуждение исходный текст |
Ответ на | Re: Urgent - SQL Unique constraint error (long) (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Список | pgsql-sql |
Stephen, I preemptivelty sensed your reply ;-) I took another look at the ERD and quickly revised phone, address, and email so they all reference the person without having to become intertwined with their extended "class". Ultimately this should prove more flexible as it will allow persons to shift from class to class if their roles change. Darrin Inheritance would have made things so much easier ..... -----Original Message----- From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org]On Behalf Of Stephan Szabo Sent: August 19, 2002 1:56 PM To: Darrin Domoney Cc: pgsql-sql@postgresql.org; pgsql-novice@postgresql.org; pgsql-admin@postgresql.org Subject: Re: [ADMIN] [SQL] Urgent - SQL Unique constraint error (long) On Mon, 19 Aug 2002, Darrin Domoney wrote: > Thanks for the response but the answer is no. Owing to the > ongoing issue with inherited tables in 7.x I have opted to create three > tables: > Contains generic traits regardless of "class or role". > Person -> PK person_id > > Staff as certain "class" of person. > Staff -> PK staff_id > FK person_id > > Contact as another "class" of person. > Contact -> PK contact_id > FK person_id > > Phone numbers relate to any "class" but are related back to > the originator by using "person_id". I now see what you're doing, but it won't work. ALTER TABLE phone_number ADD CONSTRAINT staff_phone FOREIGN KEY ( person_id ) REFERENCES staff ( person_id ) NOT DEFERRABLE; ALTER TABLE phone_number ADD CONSTRAINT contact_phone_number FOREIGN KEY ( person_id ) REFERENCES contact ( person_id ) NOT DEFERRABLE; means that the person_id in phone number must be in *both* contact and staff. Are there classes of person that you don't want phone_number to be able to reference? If not, you should be referencing person(person_id). If so, I'm not sure I have an answer for you apart from hacking triggers since even if inheritance worked, it wouldn't really help you there. ---------------------------(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
В списке pgsql-sql по дате отправления: