2015-03-06 3 views
0

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

Есть еще две таблицы. Первый - red_boxes и второй blue_boxes.

Я добавил ограничение на таблицу red_boxes

ALTER TABLE red_boxes 
ADD CONSTRAINT fk_box_id 
FOREIGN KEY (box_id) 
REFERENCES boxes (box_id); 

Теперь я хотел бы добавить ограничение на таблицу blue_boxes. Структура SQL выглядела бы следующим образом, если бы я не добавлял ограничение уже к red_boxes. Очевидный способ исправить это - назвать новое ограничение по-другому, например. fk_box_id2, но это хороший способ? Должен ли я как-то повторно использовать предыдущее ограничение, или это невозможно, почему?

ALTER TABLE blue_boxes 
ADD CONSTRAINT fk_box_id 
FOREIGN KEY (box_id) 
REFERENCES boxes (box_id) 
+1

Идентификатор ограничения - это идентификатор, который идентифицирует ограничение, как PK для ограничений (как пример). Поэтому у вас не может быть двух ограничений с тем же именем. Хорошая оценка заключается в том, чтобы называть ограничение частью таблицы, которая принадлежит ей как 'fk_boxid # redbox' и' fk_boxid # bluebox' (# это просто соглашение, которое я использую), чтобы не экстраполировать ограничение имени с помощью, в оракул, если я помню, 30 символов –

ответ

3

Каждое ограничение является отдельным и требует уникального имени. Моя рекомендация заключается в использовании имен исходной и целевой таблиц, например fk_red_boxes_boxes и fk_blue_boxes_boxes. Таким образом, вы можете легко определить, откуда они и куда они идут.

Если у вас есть символы подчеркивания в именах таблиц, вы можете придумать измененное соглашение, которое вы можете легко понять с первого взгляда. Например, двойной знак подчеркивания: fk__blue_boxes__boxes и fk__red_boxes__boxes.

+0

Я предпочитаю идею Хорхе использовать другого персонажа, например $ или # - лучше использовать ограничение на 30 символов. –

Смежные вопросы