zéro ou un à zéro ou un

Comment modéliser la relation zéro ou un à zéro ou un dans Sql Server de la manière la plus naturelle?

Il existe un tableau des «dangers» qui répertorie les dangers sur un site. Il existe une table «Tâche» pour le travail qui doit être effectué sur un site. Certaines tâches consistent à corriger un danger, aucune tâche ne peut faire face à plusieurs dangers. Certains dangers ont pour tâche de les résoudre. Aucun danger ne peut être associé à deux tâches.

Ce qui suit est le meilleur auquel j'ai pu penser:

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

Le feriez-vous différemment? La raison pour laquelle je ne suis pas satisfait de cette configuration est qu'il doit y avoir une logique d'application pour s'assurer que les tâches et les dangers pointent les uns vers les autres et non vers d'autres tâches et dangers et qu'aucune tâche / danger ne pointe vers le même danger / tâche. une autre tâche / un danger indique.

Y a-t-il une meilleure façon?

Vous pouvez utiliser votre propre idée d'un schéma asymétrique en supprimant l'une des clés étrangères de la configuration actuelle, ou, pour garder la symétrie, vous pouvez supprimer les deux clés étrangères et introduire une table de jonction avec une contrainte unique sur chaque référence. .

Donc, ce serait comme ça:

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

Vous pouvez également déclarer (HazardId, TaskId)être la clé primaire si vous devez référencer ces combinaisons à partir d'une autre table. Dans le but de garder les paires uniques, cependant, la clé primaire n'est pas nécessaire, il suffit que chaque ID soit unique.

Pour résumer:

• Les dangers ont une ou zéro tâche
• Les tâches comportent un ou zéro danger

Si les tableaux des tâches et des dangers sont utilisés pour autre chose (c'est-à-dire que les tâches et / ou les dangers ont d'autres données associées et que le modèle que vous nous avez montré est simplifié pour ne montrer que les champs pertinents), je dirais que votre solution est correcte.

Sinon, si les tâches et les dangers n'existent que pour être couplés les uns aux autres, vous n'avez pas besoin de deux tables; vous pouvez créer une seule table pour leur relation, avec les champs suivants:

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

Une autre approche qui ne semble pas encore être mentionnée consiste à faire en sorte que les dangers et les tâches utilisent le même espace d'identification. Si un danger a une tâche, il aura le même ID. Si une tâche concerne un danger, elle aura le même ID.

Vous utiliseriez une séquence plutôt que des colonnes d'identité pour remplir ces ID.

Les requêtes sur ce type de modèle de données utiliseraient des jointures externes (complètes) pour récupérer leurs résultats.

Cette approche est très similaire à la réponse de @ AndriyM, sauf que sa réponse permet que les ID soient différents et une table pour stocker cette relation.

Je ne suis pas sûr que vous souhaitiez utiliser cette approche pour un scénario à deux tables, mais cela fonctionne bien lorsque le nombre de tables impliquées augmente.