SQL многие-ко-многим между таблицами 3

Question

У меня есть следующие таблицы:

Users 
- user_id (PK) 

Projects 
- project_id (PK) 

Tasks 
- taks_id (PK) 
- project_id (FK) 

Требования:

• Каждая Задача принадлежит только один проект.
• В каждом проекте есть один или несколько пользователей.
• Каждая задача имеет 0 или более пользователей (но пользователи должны принадлежать проекту, к которому принадлежит задача).

В настоящее время я пытаюсь сделать выше 2 объединения таблиц:

UsersProjects 
[user_id] INT   NOT NULL, 
[project_id] INT   NOT NULL, 
[accepted] BIT NULL, 
FOREIGN KEY ([user_id]) REFERENCES [dbo].[_Users] ([user_id]), 
FOREIGN KEY ([project_id]) REFERENCES [dbo].[_Projects] ([project_id]), 
CONSTRAINT [PK_UsersProjects] PRIMARY KEY ([user_id], [project_id]) 

UsersTasks 
[user_id] INT   NOT NULL, 
[task_id] INT   NOT NULL, 
[accepted] BIT NULL, 
FOREIGN KEY ([user_id]) REFERENCES [dbo].[_Users] ([user_id]), 
FOREIGN KEY ([task_id]) REFERENCES [dbo].[_Tasks] ([task_id]), 
CONSTRAINT [PK_UsersTasks] PRIMARY KEY ([user_id], [task_id]) 

Я на правильном пути, для многих-ко-многим и для требований? Как я могу его оптимизировать?

Спасибо, что нашли время, чтобы прочитать это!

Answer 1

В каждой задаче 0 или более пользователей (но пользователи должны принадлежать проекту, к которому принадлежит задача).

Я предполагаю, что вы спрашиваете, как применить это последнее ограничение - его нет в вашей текущей схеме БД. Я вижу два варианта:

1. Вы должны сделать это с помощью SQL (например, при вставке записи в UsersTasks вы выдаете SELECT, на UsersProjects РЕГИСТРИРУЙТЕСЬ Задачи, чтобы увидеть, если есть по крайней мере запись соответствие)
2. Вы изменить структура основного ключа задач. То есть вы создаете PK для соединения (Project_ID + Task_ID), а Task_ID больше не является идентификационным полем, но начинается с, например. 1 для каждого нового проекта. Затем PK для UsersTasks также становится User_ID + Project_ID + Task_ID, а затем вы можете ссылаться на полностью FK прямо на UserProjects (User_ID + Project_ID). Он менее интуитивно понятен, чем решение 1, но работает и не требует специального SQL для обеспечения целостности.

Для варианта 2:

Задачи имеет несколько иное ограничение

... 
CONSTRAINT [PK_Tasks] PRIMARY KEY ([project_id], [task_id]) 

UsersTasks 
[user_id] INT   NOT NULL, 
[project_id] INT  NOT NULL, 
[task_id] INT   NOT NULL, 
[accepted] BIT NULL, 
FOREIGN KEY ([user_id]) REFERENCES [dbo].[_Users] ([user_id]), 
FOREIGN KEY ([project_id], [task_id]) REFERENCES [dbo].[_Tasks] ([project_id],[task_id]), 
FOREIGN KEY ([user_id], [project_id]) REFERENCES [dbo].[_User_Projects] ([user_id],[project_id]), 
CONSTRAINT [PK_UsersTasks] PRIMARY KEY ([user_id], [project_id], [task_id])