Foreign Key ไปยังหลาย ๆ ตาราง

ฉันมี 3 ตารางที่เกี่ยวข้องในฐานข้อมูลของฉัน

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
)

ผู้ใช้อยู่ในหลายกลุ่ม สิ่งนี้ทำได้ผ่านความสัมพันธ์แบบกลุ่มต่อกลุ่มมาก แต่ไม่เกี่ยวข้องในกรณีนี้ ตั๋วสามารถเป็นเจ้าของได้ทั้งกลุ่มหรือผู้ใช้ผ่านช่อง dbo.Ticket.Owner

อะไรคือวิธีที่ถูกต้องที่สุดในการอธิบายความสัมพันธ์ระหว่างตั๋วกับผู้ใช้หรือกลุ่มทางเลือก

ฉันคิดว่าควรเพิ่มธงในตารางตั๋วที่ระบุว่าประเภทใดเป็นเจ้าของ

คุณมีทางเลือกสองสามทางซึ่งทั้งหมดนี้มีความ "ถูกต้อง" และความสะดวกในการใช้ เช่นเคยการออกแบบที่เหมาะสมขึ้นอยู่กับความต้องการของคุณ

• คุณสามารถสร้างสองคอลัมน์ใน Ticket, OwnedByUserId และ OwnedByGroupId และมี Foreign Keys ที่เป็นโมฆะในแต่ละตารางได้

• คุณสามารถสร้างตารางอ้างอิง M: M เพื่อเปิดใช้งานทั้ง ticket: user และ ticket: group relationship บางทีในอนาคตคุณอาจต้องการอนุญาตให้ตั๋วใบเดียวเป็นของผู้ใช้หลายคนหรือหลายกลุ่ม? การออกแบบนี้ไม่ได้บังคับว่าตั๋วจะต้องเป็นของเอนทิตีเดียวเท่านั้น

• คุณสามารถสร้างกลุ่มเริ่มต้นสำหรับผู้ใช้ทุกคนและมีตั๋วที่เป็นของกลุ่มจริงหรือกลุ่มเริ่มต้นของผู้ใช้

• หรือ (ทางเลือกของฉัน) สร้างโมเดลเอนทิตีที่ทำหน้าที่เป็นฐานสำหรับทั้งผู้ใช้และกลุ่มและมีตั๋วที่เป็นของเอนทิตีนั้น

นี่คือตัวอย่างคร่าวๆโดยใช้สคีมาที่คุณโพสต์ไว้:

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
)

ตัวเลือกแรกในรายการของ@Nathan Skerlคือสิ่งที่ดำเนินการในโครงการที่ฉันเคยทำงานด้วยซึ่งมีการสร้างความสัมพันธ์ที่คล้ายกันระหว่างสามตาราง (หนึ่งในนั้นอ้างถึงอีกสองคนทีละคน)

ดังนั้นตารางอ้างอิงจึงมีคอลัมน์คีย์ต่างประเทศสองคอลัมน์และยังมีข้อ จำกัด ในการรับประกันว่าตารางเดียว (ไม่ใช่ทั้งคู่ไม่ใช่ทั้งคู่) ถูกอ้างอิงโดยแถวเดียว

นี่คือลักษณะที่ปรากฏเมื่อนำไปใช้กับตารางของคุณ:

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

ดังที่คุณเห็นTicketตารางมีสองคอลัมน์OwnerGroupและOwnerUserทั้งสองเป็นคีย์ต่างประเทศที่เป็นโมฆะ (คอลัมน์ที่เกี่ยวข้องในอีกสองตารางจะถูกสร้างเป็นคีย์หลักตามนั้น) CK_Ticket_GroupUserข้อ จำกัด ในการตรวจสอบจะทำให้แน่ใจว่ามีเพียงคอลัมน์คีย์ต่างประเทศหนึ่งในสองคอลัมน์เท่านั้นที่มีการอ้างอิง (อีกคอลัมน์หนึ่งเป็นโมฆะนั่นคือเหตุผลที่ทั้งสองต้องเป็นโมฆะ)

(คีย์หลักTicket.IDไม่จำเป็นสำหรับการใช้งานนี้ แต่แน่นอนว่าจะไม่เป็นอันตรายต่อการมีหนึ่งในตารางเช่นนี้)

อีกทางเลือกหนึ่งคือมีในTicketหนึ่งคอลัมน์ระบุประเภทเอนทิตีที่เป็นเจ้าของ ( UserหรือGroup) คอลัมน์ที่สองที่มีการอ้างอิงUserหรือGroupรหัสและไม่ใช้ Foreign Keys แต่ใช้ Trigger เพื่อบังคับใช้ referential Integrity แทน

ข้อดีสองประการที่ฉันเห็นจากโมเดลที่ยอดเยี่ยมของนาธาน(ด้านบน):

• ชัดเจนและเรียบง่ายมากขึ้นในทันที
• ข้อความค้นหาที่ง่ายกว่าในการเขียน

อีกวิธีหนึ่งคือการสร้างตารางการเชื่อมโยงที่มีคอลัมน์สำหรับทรัพยากรที่มีศักยภาพแต่ละประเภท ในตัวอย่างของคุณเจ้าของที่มีอยู่ทั้งสองประเภทมีตารางของตัวเอง (ซึ่งหมายความว่าคุณมีสิ่งที่ต้องอ้างอิง) หากเป็นเช่นนี้เสมอคุณสามารถมีสิ่งนี้:

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
)

ด้วยโซลูชันนี้คุณจะยังคงเพิ่มคอลัมน์ใหม่ต่อไปเมื่อคุณเพิ่มเอนทิตีใหม่ลงในฐานข้อมูลและคุณจะลบและสร้างรูปแบบข้อ จำกัด คีย์ต่างประเทศที่แสดงโดย @Nathan Skerl โซลูชันนี้คล้ายกับ @Nathan Skerl มาก แต่ดูแตกต่างกัน (ขึ้นอยู่กับความชอบ)

หากคุณจะไม่มีตารางใหม่สำหรับ Owner ใหม่แต่ละประเภทอาจเป็นการดีที่จะรวม owner_type แทนคอลัมน์ Foreign Key สำหรับเจ้าของที่มีศักยภาพแต่ละราย:

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
)

ด้วยวิธีการข้างต้นคุณสามารถเพิ่มประเภทเจ้าของได้มากเท่าที่คุณต้องการ Owner_ID จะไม่มีข้อ จำกัด ของคีย์ภายนอก แต่จะใช้อ้างอิงไปยังตารางอื่น ๆ ข้อเสียคือคุณจะต้องดูตารางเพื่อดูว่าเจ้าของประเภทนั้นมีอะไรบ้างเนื่องจากไม่ชัดเจนในทันทีตามสคีมา ฉันจะแนะนำสิ่งนี้ก็ต่อเมื่อคุณไม่ทราบประเภทของเจ้าของล่วงหน้าและพวกเขาจะไม่เชื่อมโยงกับตารางอื่น ๆ ถ้าคุณรู้จักประเภทของเจ้าของมาก่อนฉันจะใช้วิธีแก้ปัญหาเช่น @Nathan Skerl

ขออภัยถ้าฉันมี SQL ผิดพลาดฉันเพิ่งโยนมันเข้าด้วยกัน

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

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

ฉันคิดว่านั่นเป็นวิธีทั่วไปที่สุดในการแสดงสิ่งที่คุณต้องการแทนที่จะใช้ธง