нуль або один до нуля або один

Як я моделюю відносини нуль або один до нуля або один на Sql Server найбільш природним способом?

Існує таблиця "небезпеки", яка містить перелік небезпек на сайті. Існує таблиця "Завдання" для роботи, яку потрібно виконати на сайті. Деякі завдання - виправити небезпеку, жодне завдання не може боротися з кількома небезпеками. Деякі небезпеки мають завдання їх усунути. Без небезпеки не може бути пов'язано з ними два завдання.

Нижче - найкраще, про що я міг придумати:

CREATE TABLE [dbo].[Hazard](
  [HazardId] [int] IDENTITY(1,1) NOT NULL,
  [TaskId] [int] NULL,
  [Details] [varchar](max) NULL,
 CONSTRAINT [PK_Hazard] PRIMARY KEY CLUSTERED 
(
  [HazardId] ASC
))

GO

ALTER TABLE [dbo].[Hazard]  WITH CHECK ADD  CONSTRAINT [FK_Hazard_Task] FOREIGN KEY([TaskId])
REFERENCES [dbo].[Task] ([TaskId])
GO


CREATE TABLE [dbo].[Task](
  [TaskId] [int] IDENTITY(1,1) NOT NULL,
  [HazardId] [int] NULL,
  [Details] [varchar](max) NULL,
 CONSTRAINT [PK_Task] PRIMARY KEY CLUSTERED 
(
  [TaskId] ASC
))

GO

ALTER TABLE [dbo].[Task]  WITH CHECK ADD  CONSTRAINT [FK_Task_Hazard] FOREIGN KEY([HazardId])
REFERENCES [dbo].[Hazard] ([HazardId])
GO

Ви зробили б це по-іншому? Причиною, що я не задоволений цим налаштуванням, є те, що потрібно застосувати логіку програми, щоб переконатися, що завдання та небезпеки вказують один на одного, а не на інші завдання та небезпеки, і що жодне завдання / небезпека не вказує на однакову небезпеку / завдання інше завдання / небезпека вказує на.

Чи є кращий спосіб?

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

Отже, було б так:

CREATE TABLE dbo.Hazard
(
  HazardId int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Hazard PRIMARY KEY CLUSTERED,
  Details varchar(max) NULL
);

CREATE TABLE dbo.Task
(
  TaskId int IDENTITY(1,1) NOT NULL CONSTRAINT PK_Task PRIMARY KEY CLUSTERED,
  Details varchar(max) NULL,
);

CREATE TABLE dbo.HazardTask
(
  HazardId int NOT NULL
    CONSTRAINT FK_HazardTask_Hazard FOREIGN KEY REFERENCES dbo.Hazard (HazardId)
    CONSTRAINT UQ_HazardTask_Hazard UNIQUE,
  TaskId int NOT NULL
    CONSTRAINT FK_HazardTask_Task FOREIGN KEY REFERENCES dbo.Task (TaskId)
    CONSTRAINT UQ_HazardTask_Task UNIQUE
);

Ви можете додатково оголосити (HazardId, TaskId)основним ключем, якщо вам потрібно посилатися на ці комбінації з іншої таблиці. З метою збереження унікальних пар, однак, первинний ключ непотрібний, достатньо, щоб кожен ідентифікатор був унікальним.

Підсумовуючи:

• Небезпеки мають одне або нульове завдання
• Завдання мають одну або нульову небезпеку

Якщо таблиці Завдання та небезпеки використовуються для чогось іншого (тобто завдання та / або небезпеки пов'язані з іншими даними, а модель, яку ви нам показали, спрощена, щоб відображати лише відповідні поля), я б сказав, що ваше рішення правильне.

В іншому випадку, якщо Завдання та небезпеки існують лише для з'єднання один з одним, вам не потрібно дві таблиці; ви можете створити єдину таблицю для їх взаємозв'язку з такими полями:

ID            int, PK
TaskID        int, (filtered) unique index  
TaskDetails   varchar
HazardID      int, (filtered) unique index
HazardDetails varchar

Інший підхід, який, здається, ще не згадується, - це мати небезпеки та завдання використовувати один і той же простір ідентифікаторів. Якщо небезпека має завдання, вона матиме той самий ідентифікатор. Якщо завдання є небезпечним, воно матиме той самий ідентифікатор.

Для заповнення цих ідентифікаторів ви використовуєте послідовність, а не стовпці ідентичності.

Запити щодо цієї моделі даних використовуватимуть (повне) зовнішнє з'єднання для отримання своїх результатів.

Цей підхід дуже схожий на відповідь @ AndriyM, за винятком його відповіді дозволяє ідентифікатори відрізнятися, а таблиця для зберігання цих відносин.

Я не впевнений, що ви хочете використовувати такий підхід для сценарію з двох таблиць, але він працює добре, коли кількість задіяних таблиць збільшується.