Jak stworzyć prawdziwą relację jeden do jednego w SQL Server

Ustaw klucz obcy jako klucz podstawowy, a następnie Ustaw relację na obu polach klucza podstawowego. To jest to! Powinieneś zobaczyć znak klucza na obu końcach linii relacji. To oznacza jeden do jednego.

Sprawdź to: Projekt bazy danych SQL Server z relacją jeden do jednego

Można to zrobić, tworząc prostą podstawową relację klucza obcego i ustawiając kolumnę klucza obcego na unique w następujący sposób:

CREATE TABLE [Employee] (
    [ID]    INT PRIMARY KEY
,   [Name]  VARCHAR(50)
);

CREATE TABLE [Salary] (
    [EmployeeID]    INT UNIQUE NOT NULL
,   [SalaryAmount]  INT 
);

ALTER TABLE [Salary]
ADD CONSTRAINT FK_Salary_Employee FOREIGN KEY([EmployeeID]) 
    REFERENCES [Employee]([ID]);

INSERT INTO [Employee] (
    [ID]
,   [Name]
)
VALUES
    (1, 'Ram')
,   (2, 'Rahim')
,   (3, 'Pankaj')
,   (4, 'Mohan');

INSERT INTO [Salary] (
    [EmployeeID]
,   [SalaryAmount]
)
VALUES
    (1, 2000)
,   (2, 3000)
,   (3, 2500)
,   (4, 3000);

Sprawdź, czy wszystko jest w porządku

SELECT * FROM [Employee];
SELECT * FROM [Salary];

Obecnie w podstawowym obcym związku (jeden do wielu), można wprowadzić wiele razy EmployeeID, ale tutaj błąd zostanie wyrzucony

INSERT INTO [Salary] (
    [EmployeeID]
,   [SalaryAmount]
)
VALUES
    (1, 3000);

Powyższa instrukcja wyświetli błąd jako

Naruszenie unikalnego ograniczenia klucza "UQ__pensja _ _ 7AD04FF0C044141D". Nie można wstawić zduplikowanego klucza w obiekcie ' dbo.Wynagrodzenie". Zduplikowaną wartością klucza jest (1).

Jest jeden sposób, w jaki wiem, jak osiągnąć ścisłą* relację jeden do jednego bez użycia wyzwalaczy, kolumn obliczeniowych, dodatkowych tabel lub innych "egzotycznych" sztuczek( tylko klucze obce i unikalne ograniczenia), z jednym małym zastrzeżeniem.

Pożyczę koncepcję kurczaka i jajka z zaakceptowanej odpowiedzi, aby pomóc mi wyjaśnić zastrzeżenie.

Faktem jest, że albo kura, albo jajko muszą być pierwsze(w obecnym DBs tak czy inaczej). Na szczęście rozwiązanie to nie ma charakteru politycznego i nie nie przepisać, który ma być pierwszy-pozostawia to do wykonawcy.

Zastrzeżenie jest takie, że tabela, która pozwala rekordowi "być pierwszym" technicznie może mieć rekord utworzony bez odpowiedniego rekordu w drugiej tabeli; jednak w tym rozwiązaniu dozwolony jest tylko jeden taki rekord. Gdy zostanie utworzony tylko jeden rekord (tylko kura lub jajko), nie można dodać więcej rekordów do żadnej z dwóch tabel, dopóki rekord "samotny" nie zostanie usunięty lub nie zostanie utworzony pasujący rekord w inny stół.

Rozwiązanie:

Dodaj klucze obce do każdej tabeli, odwołując się do drugiej, dodaj unikalne ograniczenia do każdego klucza obcego i ustaw jeden klucz obcy jako nullable, drugi nie jako nullable, a także klucz podstawowy. Aby to zadziałało, unikalna ograniczenie w kolumnie nullable musi zezwalać tylko na jedno null (tak jest w SQL Server, nie jest pewne co do innych baz danych).

CREATE TABLE dbo.Egg (
    ID int identity(1,1) not null,
    Chicken int null,
    CONSTRAINT [PK_Egg] PRIMARY KEY CLUSTERED ([ID] ASC) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE dbo.Chicken (
    Egg int not null,
    CONSTRAINT [PK_Chicken] PRIMARY KEY CLUSTERED ([Egg] ASC) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE dbo.Egg  WITH NOCHECK ADD  CONSTRAINT [FK_Egg_Chicken] FOREIGN KEY([Chicken]) REFERENCES [dbo].[Chicken] ([Egg])
GO
ALTER TABLE dbo.Chicken  WITH NOCHECK ADD  CONSTRAINT [FK_Chicken_Egg] FOREIGN KEY([Egg]) REFERENCES [dbo].[Egg] ([ID])
GO
ALTER TABLE dbo.Egg WITH NOCHECK ADD CONSTRAINT [UQ_Egg_Chicken] UNIQUE([Chicken])
GO
ALTER TABLE dbo.Chicken WITH NOCHECK ADD CONSTRAINT [UQ_Chicken_Egg] UNIQUE([Egg])
GO

Aby wstawić, najpierw należy wstawić jajko (z null dla kurczaka). Teraz Można włożyć tylko kurczaka i musi odnosić się do "nieodebranego" jaja. Wreszcie dodane jajko może zostać zaktualizowane i musi odnosić się do "nieodebranego" kurczaka. W żadnym momencie nie można zmusić dwóch kurcząt do odniesienia się do tego samego jaja lub odwrotnie.

To rozwiązanie pozwala również na łatwą wymianę. Co ciekawe, zamiana może być najsilniejszym argumentem za zastosowaniem takiego rozwiązania, ponieważ ma potencjalne praktyczne zastosowanie. Zwykle w większości przypadków relacja jeden do jednego dwóch tabel jest lepiej zaimplementowana przez zwykłe refaktoryzację dwóch tabel w jedną; jednak w potencjalnym scenariuszu dwie tabele mogą reprezentować naprawdę odrębne podmioty, które wymagają ścisłej relacji jeden do jednego, ale muszą często wymieniać się "partnerami" lub być ponownie ułożone w ogóle, przy jednoczesnym utrzymaniu relacji jeden do jednego po ponownym ułożeniu. Jeśli zastosowano bardziej powszechne rozwiązanie, wszystkie kolumny danych jeden z elementów musiałby być zaktualizowany/nadpisany dla wszystkich par, które są ponownie ułożone, w przeciwieństwie do tego rozwiązania, gdzie tylko jedna kolumna kluczy obcych musi być ponownie ułożona (nullable foreign key column).

Cóż, to jest najlepsze co mogłem zrobić używając standardowych ograniczeń (nie oceniaj:) może komuś się to przyda.

Relacje 1 do 1 w SQL są tworzone przez połączenie pola obu tabel w jeden !

Wiem, że można podzielić tabelę na dwie jednostki z relacją 1 do 1. Najczęściej używasz tego, ponieważ chcesz korzystać z leniwego ładowania na "ciężkim polu danych binarnych w tabeli".

Exemple: masz tabelę zawierającą zdjęcia z kolumną z nazwą (string), może jakąś kolumną metadanych, kolumną miniatury i samym obrazem varbinary (max). W swojej aplikacji na pewno wyświetli najpierw tylko nazwa i miniaturka w kontrolce kolekcji, a następnie załaduj "Pełne Dane obrazu" tylko w razie potrzeby.

Jeśli to jest to, czego szukasz. Jest to coś, co nazywa się "podział tabeli" lub "podział poziomy".

Https://visualstudiomagazine.com/articles/2014/09/01/splitting-tables.aspx

Najprostszym sposobem na osiągnięcie tego celu jest utworzenie tylko 1 tabeli z polami tabeli a i B bez NULL. W ten sposób nie można mieć jednego bez drugiego.

A co z tym ?

create table dbo.[Address]
(
Id int identity not null,
City nvarchar(255) not null,
Street nvarchar(255) not null,
CONSTRAINT PK_Address PRIMARY KEY (Id)
)

create table dbo.[Person]
(
Id int identity not null,
AddressId int not null,
FirstName nvarchar(255) not null,
LastName nvarchar(255) not null,
CONSTRAINT PK_Person PRIMARY KEY (Id),
CONSTRAINT FK_Person_Address FOREIGN KEY (AddressId) REFERENCES dbo.[Address] (Id)
)

Relacja 1 do 1 jest bardzo możliwa. Nawet jeśli diagram relacji nie pokazuje bezpośrednio relacji 1 do 1. Jeśli zaimplementujesz go jak poniżej, będzie działał jako relacja jeden do jednego.

Użyję podstawowego przykładu, aby wyjaśnić koncepcję, w której jedna osoba może mieć tylko jeden paszport. Ten przykład doskonale sprawdza się w MS Access. Dla wersji SQL Server wykonaj ten link .

Pamiętaj, że w MS Access skrypty SQL mogą być uruchamiane tylko w czas, a nie jak wyświetlane tutaj w kolejności.

CREATE TABLE Person
(
Pk_Person_Id INT PRIMARY KEY,
Name VARCHAR(255),
EmailId VARCHAR(255),
);

CREATE TABLE PassportDetails
(
Pk_Passport_Id INT PRIMARY KEY,
Passport_Number VARCHAR(255),
Fk_Person_Id INT NOT NULL UNIQUE, 
FOREIGN KEY(Fk_Person_Id) REFERENCES Person(Pk_Person_Id)
);