sıfır veya bir ile sıfır veya bir

Sql Server'da sıfır veya bir ile sıfır veya bir ilişkisini en doğal şekilde nasıl modelleyebilirim?

Bir sitedeki tehlikeleri listeleyen bir 'Tehlike' tablosu vardır. Bir sitede yapılması gereken işler için bir 'Görev' tablosu vardır. Bazı Görevler bir tehlikeyi düzeltmek içindir, hiçbir görev birden fazla tehlikeyle başa çıkamaz. Bazı Tehlikelerin bunları düzeltmek gibi bir görevi vardır. Hiçbir tehlikenin kendisiyle ilişkili iki görevi olamaz.

Aşağıda aklıma gelen en iyisi var:

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

Bunu farklı yapar mısın? Bu kurulumdan memnun olmamamın nedeni, görevlerin ve tehlikelerin diğer görev ve tehlikeleri değil, birbirlerini işaret ettiğinden ve aynı tehlike / görevi gösteren hiçbir görev / tehlikenin olmadığından emin olmak için uygulama mantığının bulunması gerektiğidir. başka bir görev / tehlike işaret eder.

Daha iyi bir yol var mı?

Mevcut kurulumdan yabancı anahtarlardan birini kaldırarak kendi asimetrik şema fikrinizle gidebilir veya şeyleri simetrik tutabilirsiniz, her iki yabancı anahtarı da kaldırabilir ve her referansta benzersiz bir kısıtlamayla bir bağlantı tablosu sunabilirsiniz. .

Yani, şöyle olur:

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

Ek (HazardId, TaskId)olarak, bu kombinasyonlara başka bir tablodan başvurmanız gerekirse birincil anahtar olduğunu bildirebilirsiniz. Ancak çiftleri benzersiz tutmak için birincil anahtar gereksizdir, her bir kimliğin benzersiz olması yeterlidir.

Sonuç olarak:

• Tehlikelerin bir veya sıfır Görevi vardır
• Görevlerin bir veya sıfır Tehlikesi var

Görev ve Tehlike tabloları başka bir şey için kullanılıyorsa (yani görevler ve / veya tehlikeler başka verilerle ilişkilendirilmişse ve bize gösterdiğiniz model sadece ilgili alanları göstermek için basitleştirilmiştir) çözümünüzün doğru olduğunu söyleyebilirim.

Aksi takdirde, Görevler ve Tehlikeler yalnızca birbirine bağlanmışsa, iki tabloya ihtiyacınız yoktur; ilişkileri için aşağıdaki alanlarla tek bir tablo oluşturabilirsiniz:

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

Henüz bahsedilmemiş gibi görünen bir diğer yaklaşım, Tehlikeler ve Görevlerin aynı kimlik alanını kullanmasıdır. Bir Tehlikenin Görevi varsa, aynı kimliğe sahip olacaktır. Bir Görev Tehlike içinse aynı kimliğe sahip olacaktır.

Bu kimlikleri doldurmak için kimlik sütunları yerine bir dizi kullanırsınız.

Bu tür veri modelindeki sorgular, sonuçlarını almak için (tam) dış birleşimleri kullanır.

Bu yaklaşım @ AndriyM'in cevabına çok benziyor, ancak yanıtı kimliklerin farklı olmasına izin veriyor ve bu ilişkiyi saklamak için bir tablo.

İki tablolu bir senaryo için bu yaklaşımı kullanmak istediğinizden emin değilim, ancak ilgili tablo sayısı arttığında iyi çalışıyor.