Внешний ключ PostgreSQL не существует, проблема наследования?

Question

Я борюсь с внешними ключами в моей БД, возможно, это как-то связано с наследованием?
Итак, вот основные настройки:

-- table address
CREATE TABLE address
(
  pk_address serial NOT NULL,
  fk_gadmid_0 integer NOT NULL, -- this table already exists, no problem here
  street character varying(100),
  zip character varying(10),
  city character varying(50),
  public boolean,
  CONSTRAINT address_primarykey PRIMARY KEY (pk_address),
  CONSTRAINT gadmid_0_primarykey FOREIGN KEY (fk_gadmid_0)
      REFERENCES adm0 (gadmid_0) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE address OWNER TO postgres;  

-- table stakeholder (parent)
CREATE TABLE stakeholder
(
    pk_stakeholder integer DEFAULT nextval('common_stakeholder_seq') NOT NULL,
    fk_stakeholder_type integer NOT NULL, -- this table also exists, no problem here
    name character varying(255) NOT NULL,
    CONSTRAINT stakeholder_primarykey PRIMARY KEY (pk_stakeholder),
    CONSTRAINT stakeholder_fk_stakeholder_type FOREIGN KEY (fk_stakeholder_type)
        REFERENCES stakeholder_type (pk_stakeholder_type) MATCH SIMPLE
        ON UPDATE CASCADE ON DELETE NO ACTION
)
WITH (
    OIDS=FALSE
);
ALTER TABLE stakeholder OWNER TO postgres;  

-- table individual (child of stakeholder)
CREATE TABLE individual
(
    firstname character varying(50),
    fk_title integer, -- this table also exists, no problem here
    email1 character varying (100),
    email2 character varying (100),
    phone1 character varying (50),
    phone2 character varying (50),
    CONSTRAINT individual_primarykey PRIMARY KEY (pk_stakeholder),
    CONSTRAINT title_foreignkey FOREIGN KEY (fk_title)
        REFERENCES title (pk_title) MATCH SIMPLE
        ON UPDATE CASCADE ON DELETE CASCADE
) INHERITS (stakeholder)
WITH (
    OIDS=FALSE
);
ALTER TABLE individual OWNER TO postgres;  

-- link between stakeholder and address
CREATE TABLE l_stakeholder_address
(
    pk_l_stakeholder_address serial NOT NULL,
    fk_stakeholder integer NOT NULL REFERENCES stakeholder,
    fk_address integer NOT NULL REFERENCES address,
    CONSTRAINT l_stakeholder_address_primarykey PRIMARY KEY (pk_l_stakeholder_address),
    CONSTRAINT l_stakeholder_address_fk_stakeholder FOREIGN KEY (fk_stakeholder)
        REFERENCES stakeholder (pk_stakeholder) MATCH SIMPLE
        ON UPDATE CASCADE ON DELETE NO ACTION,
    CONSTRAINT l_stakeholder_address_fk_address FOREIGN KEY (fk_address)
        REFERENCES address (pk_address) MATCH SIMPLE
        ON UPDATE CASCADE ON DELETE NO ACTION
)
WITH (
    OIDS=FALSE
);
ALTER TABLE l_stakeholder_address OWNER TO postgres;

Пока проблем нет.Затем я попытался добавить некоторые значения:

INSERT INTO individual (pk_stakeholder, fk_stakeholder_type, name, firstname, fk_title, email1, email2, phone1, phone2) 
  VALUES (1, 8, 'Lastname', 'Firstname', 1, 'me@you.com', '', '', '');
INSERT INTO address (pk_address, fk_gadmid_0, street, zip, city, public)  
  VALUES (1, 126, 'Address', '', 'City', FALSE);
INSERT INTO l_stakeholder_address (pk_l_stakeholder_address, fk_stakeholder, fk_address)  
  VALUES (DEFAULT, 1, 1);

И, наконец, в итоге у меня возникла ошибка (состояние SQL 23503), говорящая о том, что ключ (fk_stakeholder) = (1) не существует в таблице "заинтересованных лиц".
Первые 2 вставки в порядке, я вижу их в базах данных:

stakeholder:
pk_stakeholder | ...
----------------------
1              | ...

address:
pk_address | ...
--------------------
1          | ...

Что я делаю не так?Я должен признать, что я довольно новичок в PostgreSQL (использую 8.4), но я даже не уверен, что это вообще проблема PG, возможно, мне просто не хватает некоторых базовых знаний о дизайне базы данных ...
В любом случаек настоящему времени я попробовал почти все, что мог придумать, я также пытался сделать FK отложенным, как в PostgreSQL: транзакция и проблема с внешним ключом , но почему-то это тоже не работает.

Answer 1

Вы можете обойти его, используя дополнительную таблицу individual_pks (individual_pk integer primary key) со всеми первичными ключами от родительского и дочернего, которые будут поддерживаться с помощью триггеров (очень просто - вставить в individual_pks при вставке, удалить из нее при удалении, обновить еепри обновлении, если оно меняется individual_pk).

Затем вы указываете внешние ключи на эту дополнительную таблицу вместо дочерней.Будет небольшое снижение производительности, но только при добавлении / удалении строк.

Или забудьте о наследовании и сделайте это по-старому - просто одну таблицу с несколькими обнуляемыми столбцами.

Answer 2

Ваш анализ совершенно прав: это из-за наследства.При проверке внешнего ключа дочерние таблицы не учитываются.

В общем случае наследование и внешние ключи плохо сочетаются в PostgreSQL.Основная проблема заключается в том, что в таблицах не может быть уникальных ограничений.

Ссылка