2015-04-15 2 views
1

У меня есть три стола.Как установить отношение внешних ключей

User 
Project 
WorkFlow 

В рабочем процессе ProjectID, UserId вместе никогда не должен повторяться. То мое требование . Я имею ввиду комбинацию никогда не повторять.

И ProjectId должен присутствовать в таблице проекта, а UserId должен присутствовать в таблице User.

Это требование.

шагов я пытался:

Я сделал ProjectId, UserId в качестве составного ключа в Workflow. Но не может поддерживать внешний ключ, поскольку две колонки недоступны в отдельной таблице.

Как это решить.

Я также могу изменить свой дизайн, так как это начальный этап моего развития.

Главная reuirement является

Одна таблицы для хранения проекта (таблица проекта), связанных информации и другой (Workflow) провести запись, проект которого назначен какого пользователь.

+0

Вы также можете обеспечить уникальность столбцов, отличных от PK, с помощью UNIQUE KEY CONSTRAINT или UNIQUE (кластерного или некрупного) INDEX? – StuartLC

+0

@StuartLC Итак, можно удалить составной ключ и сделать эти два столбца уникальным? – shanmugharaj

+1

Да, как @ ответ Роджера ниже (+1), хотя и предлагаю вам назвать UKC. – StuartLC

ответ

2

Внешние ключи не контролируют уникальность; они только контролируют ссылочную целостность. Для единственности, необходимо уникальные ограничения:

create table dbo.Workflow (
    Id int identity(1,1) primary key, 
    ProjectId int not null, 
    UserId int not null, 
    foreign key (ProjectId) references dbo.Project (Id), 
    foreign key (UserId) references dbo.[User] (Id), 
    unique (UserId, ProjectId) 
); 

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

create table dbo.Workflow (
    ProjectId int not null, 
    UserId int not null, 
    primary key (UserId, ProjectId) 
    foreign key (ProjectId) references dbo.Project (Id), 
    foreign key (UserId) references dbo.[User] (Id), 
); 

И да, ограничения должны быть уникальными именами, он будет сравнивать схемы и обновления гораздо проще.

+0

Привет, спасибо за ответ .. Да, внешние ключи не делают уникальности, мне это нужно только для ссылочной целостности. Fine, я изменю их на уникальные ключи. – shanmugharaj

+0

Ответ в основном верный, но есть одна ошибка, которую новички делают с ** Ассоциативными таблицами **. Здесь поле «id» и индекс совершенно лишние, это нецелесообразно. Понятие о том, что это PK, является результатом штамповки каждого файла с полем «id» и объявлением его «PK», который неверен. Отбросьте поле id и индекс. Затем сделайте '(UserId, ProjectId)' Первичный ключ. Потому что это. – PerformanceDBA

+0

@PerformanceDBA, обычно вы были бы правы.Однако, судя по предметной области, я решил, что у ОП, скорее всего, будет несколько таблиц под этим. И поскольку у большинства людей есть проблемы с пониманием нескольких внешних ключей столбца, я решил добавить суррогатную ПК. Если бы моя догадка была правильной, она также решила проблему «перемещение» (переход на другой проект/пользователь), что в противном случае привело бы к обновлению PK и потребовало бы 'on update cascade', что обычно нежелательно. Но да, это просто догадка. –

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