Kunci Asing ke beberapa tabel

Saya punya 3 tabel yang relevan di database saya.

CREATE TABLE dbo.Group
(
    ID int NOT NULL,
    Name varchar(50) NOT NULL
)  

CREATE TABLE dbo.User
(
    ID int NOT NULL,
    Name varchar(50) NOT NULL
)

CREATE TABLE dbo.Ticket
(
    ID int NOT NULL,
    Owner int NOT NULL,
    Subject varchar(50) NULL
)

Pengguna termasuk dalam beberapa grup. Ini dilakukan melalui hubungan banyak ke banyak, tetapi tidak relevan dalam kasus ini. Tiket dapat dimiliki oleh grup atau pengguna, melalui kolom dbo.Ticket.Owner.

Cara apa yang PALING BENAR menggambarkan hubungan antara tiket dan secara opsional pengguna atau grup?

Saya berpikir bahwa saya harus menambahkan bendera di tabel tiket yang mengatakan jenis apa yang memilikinya.

Anda memiliki beberapa pilihan, semuanya bervariasi dalam "kebenaran" dan kemudahan penggunaan. Seperti biasa, desain yang tepat bergantung pada kebutuhan Anda.

• Anda cukup membuat dua kolom di Ticket, OwnedByUserId dan OwnedByGroupId, dan memiliki Kunci Asing nullable untuk setiap tabel.

• Anda dapat membuat tabel referensi M: M yang mengaktifkan hubungan tiket: pengguna dan tiket: grup. Mungkin di masa mendatang Anda ingin mengizinkan satu tiket dimiliki oleh banyak pengguna atau grup? Desain ini tidak memaksakan bahwa tiket harus dimiliki oleh satu entitas saja.

• Anda dapat membuat grup default untuk setiap pengguna dan memiliki tiket yang hanya dimiliki oleh Grup sebenarnya atau Grup default Pengguna.

• Atau (pilihan saya) membuat model entitas yang bertindak sebagai basis untuk Pengguna dan Grup, dan memiliki tiket yang dimiliki oleh entitas tersebut.

Berikut adalah contoh kasar menggunakan skema yang Anda posting:

create table dbo.PartyType
(   
    PartyTypeId tinyint primary key,
    PartyTypeName varchar(10)
)

insert into dbo.PartyType
    values(1, 'User'), (2, 'Group');


create table dbo.Party
(
    PartyId int identity(1,1) primary key,
    PartyTypeId tinyint references dbo.PartyType(PartyTypeId),
    unique (PartyId, PartyTypeId)
)

CREATE TABLE dbo.[Group]
(
    ID int primary key,
    Name varchar(50) NOT NULL,
    PartyTypeId as cast(2 as tinyint) persisted,
    foreign key (ID, PartyTypeId) references Party(PartyId, PartyTypeID)
)  

CREATE TABLE dbo.[User]
(
    ID int primary key,
    Name varchar(50) NOT NULL,
    PartyTypeId as cast(1 as tinyint) persisted,
    foreign key (ID, PartyTypeId) references Party(PartyID, PartyTypeID)
)

CREATE TABLE dbo.Ticket
(
    ID int primary key,
    [Owner] int NOT NULL references dbo.Party(PartyId),
    [Subject] varchar(50) NULL
)

Opsi pertama dalam daftar @Nathan Skerl adalah apa yang diimplementasikan dalam proyek yang pernah saya tangani, di mana hubungan serupa dibuat antara tiga tabel. (Salah satunya mereferensikan dua lainnya, satu per satu.)

Jadi, tabel referensi memiliki dua kolom kunci asing, dan juga memiliki batasan untuk menjamin bahwa tepat satu tabel (tidak keduanya, tidak keduanya) direferensikan oleh satu baris.

Berikut tampilannya saat diterapkan ke tabel Anda:

CREATE TABLE dbo.[Group]
(
    ID int NOT NULL CONSTRAINT PK_Group PRIMARY KEY,
    Name varchar(50) NOT NULL
);

CREATE TABLE dbo.[User]
(
    ID int NOT NULL CONSTRAINT PK_User PRIMARY KEY,
    Name varchar(50) NOT NULL
);

CREATE TABLE dbo.Ticket
(
    ID int NOT NULL CONSTRAINT PK_Ticket PRIMARY KEY,
    OwnerGroup int NULL
      CONSTRAINT FK_Ticket_Group FOREIGN KEY REFERENCES dbo.[Group] (ID),
    OwnerUser int NULL
      CONSTRAINT FK_Ticket_User  FOREIGN KEY REFERENCES dbo.[User]  (ID),
    Subject varchar(50) NULL,
    CONSTRAINT CK_Ticket_GroupUser CHECK (
      CASE WHEN OwnerGroup IS NULL THEN 0 ELSE 1 END +
      CASE WHEN OwnerUser  IS NULL THEN 0 ELSE 1 END = 1
    )
);

Seperti yang Anda lihat, Tickettabel memiliki dua kolom, OwnerGroupdan OwnerUser, keduanya merupakan kunci asing yang dapat dinihilkan. (Kolom masing-masing di dua tabel lainnya dibuat sebagai kunci utama.) CK_Ticket_GroupUserBatasan pemeriksaan memastikan bahwa hanya satu dari dua kolom kunci asing yang berisi referensi (yang lainnya adalah NULL, itulah mengapa keduanya harus nullable).

(Kunci utama pada Ticket.IDtidak diperlukan untuk penerapan khusus ini, tetapi pasti tidak ada salahnya untuk memilikinya di tabel seperti ini.)

Namun opsi lain adalah memiliki, di Ticket, satu kolom yang menentukan jenis entitas pemilik ( Useratau Group), kolom kedua dengan referensi Useratau Groupid dan TIDAK menggunakan Kunci Asing melainkan mengandalkan Pemicu untuk menegakkan integritas referensial.

Dua keunggulan yang saya lihat di sini dibandingkan model Nathan yang luar biasa (di atas):

• Kejelasan dan kesederhanaan yang lebih langsung.
• Kueri yang lebih sederhana untuk ditulis.

Pendekatan lain adalah membuat tabel asosiasi yang berisi kolom untuk setiap jenis sumber daya potensial. Dalam contoh Anda, masing-masing dari dua tipe pemilik yang ada memiliki tabelnya sendiri (yang berarti Anda memiliki sesuatu untuk dirujuk). Jika ini akan selalu terjadi, Anda dapat memiliki sesuatu seperti ini:

CREATE TABLE dbo.Group
(
    ID int NOT NULL,
    Name varchar(50) NOT NULL
)  

CREATE TABLE dbo.User
(
    ID int NOT NULL,
    Name varchar(50) NOT NULL
)

CREATE TABLE dbo.Ticket
(
    ID int NOT NULL,
    Owner_ID int NOT NULL,
    Subject varchar(50) NULL
)

CREATE TABLE dbo.Owner
(
    ID int NOT NULL,
    User_ID int NULL,
    Group_ID int NULL,
    {{AdditionalEntity_ID}} int NOT NULL
)

Dengan solusi ini, Anda akan terus menambahkan kolom baru saat Anda menambahkan entitas baru ke database dan Anda akan menghapus serta membuat ulang pola batasan kunci asing yang ditunjukkan oleh @Nathan Skerl. Solusi ini sangat mirip dengan @Nathan Skerl tetapi terlihat berbeda (tergantung preferensi).

Jika Anda tidak akan memiliki Tabel baru untuk setiap jenis Pemilik baru, maka mungkin akan lebih baik untuk menyertakan tipe_milik daripada kolom kunci asing untuk setiap Pemilik potensial:

CREATE TABLE dbo.Group
(
    ID int NOT NULL,
    Name varchar(50) NOT NULL
)  

CREATE TABLE dbo.User
(
    ID int NOT NULL,
    Name varchar(50) NOT NULL
)

CREATE TABLE dbo.Ticket
(
    ID int NOT NULL,
    Owner_ID int NOT NULL,
    Owner_Type string NOT NULL, -- In our example, this would be "User" or "Group"
    Subject varchar(50) NULL
)

Dengan metode di atas, Anda dapat menambahkan Jenis Pemilik sebanyak yang Anda inginkan. Owner_ID tidak akan memiliki batasan kunci asing tetapi akan digunakan sebagai referensi ke tabel lain. Kelemahannya adalah Anda harus melihat tabel untuk melihat apa tipe pemiliknya karena tidak segera terlihat berdasarkan skema. Saya hanya akan menyarankan ini jika Anda tidak mengetahui jenis pemilik sebelumnya dan mereka tidak akan ditautkan ke tabel lain. Jika Anda mengetahui tipe pemilik sebelumnya, saya akan menggunakan solusi seperti @Nathan Skerl.

Maaf jika saya salah SQL, saya baru saja menyatukannya.

CREATE TABLE dbo.OwnerType
(
    ID int NOT NULL,
    Name varchar(50) NULL
)

insert into OwnerType (Name) values ('User');
insert into OwnerType (Name) values ('Group');

Saya pikir itu akan menjadi cara paling umum untuk mewakili apa yang Anda inginkan daripada menggunakan sebuah bendera.