zero-or-one to zero-or-one

Come modellare la relazione da zero a uno a zero o uno in SQL Server nel modo più naturale?

Esiste una tabella "Hazard" che elenca i pericoli in un sito. Esiste una tabella "Attività" per il lavoro che deve essere svolto su un sito. Alcune attività consistono nel correggere un pericolo, nessuna attività può gestire più pericoli. Alcuni pericoli hanno il compito di risolverli. A nessun pericolo possono essere associati due compiti.

Di seguito è il migliore che mi viene in mente:

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

Lo faresti diversamente? Il motivo per cui non sono soddisfatto di questa configurazione è che è necessario disporre di una logica applicativa per assicurarsi che le attività e i pericoli puntino l'una verso l'altra e non verso altre attività e pericoli e che nessuna attività / pericolosità indichi la stessa pericolosità / attività un'altra attività / pericolo indica.

Esiste un modo migliore?

Potresti andare con la tua idea di uno schema asimmetrico rimuovendo una delle chiavi esterne dall'impostazione corrente oppure, per mantenere le cose simmetriche, puoi rimuovere entrambe le chiavi esterne e introdurre una tabella di giunzione con un vincolo univoco su ciascun riferimento .

Quindi, sarebbe così:

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
);

È inoltre possibile dichiarare (HazardId, TaskId)di essere la chiave primaria se è necessario fare riferimento a queste combinazioni da un'altra tabella. Allo scopo di mantenere uniche le coppie, tuttavia, la chiave primaria non è necessaria, è sufficiente che ogni ID sia univoco.

Per riassumere:

• I pericoli hanno uno o zero compiti
• Le attività hanno uno o zero pericoli

Se le tabelle Task e Hazard vengono utilizzate per qualcos'altro (ad es. Task e / o hazard hanno altri dati associati e il modello che ci hai mostrato è semplificato per mostrare solo i campi pertinenti) direi che la tua soluzione è corretta.

Altrimenti, se Compiti e pericoli esistono solo per essere accoppiati tra loro, non sono necessarie due tabelle; puoi creare una singola tabella per la loro relazione, con i seguenti campi:

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

Un altro approccio che sembra non essere ancora stato menzionato è quello di fare in modo che Hazards and Tasks utilizzino lo stesso spazio ID. Se un Hazard ha un'attività, avrà lo stesso ID. Se un'attività è relativa a un pericolo, avrà lo stesso ID.

Utilizzerai una sequenza anziché le colonne identità per popolare questi ID.

Le query su questo tipo di modello di dati utilizzerebbero join (completi) esterni per recuperare i loro risultati.

Questo approccio è molto simile alla risposta di @ AndriyM, tranne per il fatto che la sua risposta consente di differenziare gli ID e una tabella per memorizzare questa relazione.

Non sono sicuro che tu voglia utilizzare questo approccio per uno scenario a due tabelle, ma funziona bene quando aumenta il numero di tabelle coinvolte.