общая последовательность для нескольких таблиц

Я пытаюсь создать последовательность, принадлежащую нескольким таблицам, чтобы иметь уникальный идентификатор для большего количества таблиц. Единственный обходной путь, о котором я могу думать, это использование nextval(blabla_id_seq) при INSERTing, но очевидно, что он не будет работать при использовании COPY (или некоторых других ситуациях, о которых я не могу сейчас думать).
Итак, кто-нибудь знает a решение или другой обходной путь для этого? Цель вопроса в основном образовательная.

Привет, Дон

LE И могу ли я реализовать глобальный первичный ключ для двух (или более) таблиц, родительской и дочерней? В настоящее время я пытался




DROP TABLE IF EXISTS child;
DROP TABLE IF EXISTS parent;

CREATE TABLE parent (
id serial PRIMARY KEY
, categ varchar(20) NOT NULL

);

CREATE TABLE child (
else varchar (30) NOT NULL
, id integer -- i have also tried with no id in child table, on;y when using   
--"id serial" does id become primary key
, CONSTRAINT PK__child PRIMARY KEY (id)

) INHERITS (parent);

COPY parent (categ)
FROM 'E:\\1\\_parent.csv'
WITH CSV;

COPY child(categ,altceva)
FROM  'E:\\1\\_child.csv'
WITH CSV;

INSERT INTO child (id,categ,altceva)
--VALUES(nextval('parent_id_seq')+3,'kid7','blabla');
VALUES(5,'kid7','blabla');

но я могу вставить дубликаты


postgresql sequence
person KSloan    schedule 07.09.2011    source источник
comment
Разве вы не можете установить значение столбца по умолчанию для nextval последовательности? Обычно так и делаешь.   -  person cdhowie    schedule 08.09.2011
comment
Это работает... единственная проблема теперь заключается в том, как применить уникальное ограничение для двух таблиц (я думал, что ПЕРВИЧНЫЙ КЛЮЧ в родительской таблице решает это, но он работает ТОЛЬКО в родительской таблице). любые элегантные решения для этого (имеется в виду отсутствие триггеры)?   -  person KSloan    schedule 08.09.2011
comment
Почему триггеры не считаются элегантными?   -  person mu is too short    schedule 08.09.2011
comment
Ну, я должен признать, что это только впечатление ... но я думаю, что есть ситуации, когда использование триггера является наиболее элегантным решением.   -  person KSloan    schedule 08.09.2011
comment
Зачем вообще нужна уникальность между таблицами?   -  person mu is too short    schedule 08.09.2011

Ответы (1)


arrow_upward
6
arrow_downward

Этот вопрос старый и все такое, но вот простой ответ.

Это похоже на какую-то модель наследования, и, на мой взгляд, естественным решением является использование общей базовой таблицы. Базовая таблица состоит как минимум из одного последовательного столбца. Опционально он может содержать поля для атрибутов, общих для всех объектов/узлов в системе.

node(serial node_id, timestamp creation_time default now())

book(integer node_id [foreign key => node.node_id], string title, timestamp published_time)
user(integer node_id [foreign key => node.node_id], string name, timestamp joined_time, string display_name)
car (integer node_id [foreign key => node.node_id], string model, timestamp manufactured_time, real miles)

Когда вы хотите добавить новый объект, или node как это было, вы сначала вставляете в node, а затем используете возвращенный автоматически сгенерированный серийный номер id для вставки дополнительных деталей в таблицы подтипов.

Это не требует каких-либо особых соображений, таких как транзакции, проверки, триггеры и т. д., и при создании никогда не произойдет сбой из-за ошибок уникальности.

В качестве расширения вы можете добавить поле string type в таблицу node и получить возможность принимать любые node_id и напрямую находить соответствующий объект.

person Supr    schedule 26.09.2012