Du har några alternativ, alla varierande i "riktighet" och användarvänlighet. Som alltid beror rätt design på dina behov.
-
Du kan helt enkelt skapa två kolumner i Ticket, OwnedByUserId och OwnedByGroupId och ha nullbara främmande nycklar till varje tabell.
-
Du kan skapa M:M referenstabeller som möjliggör både biljett:användare och biljett:grupp. Kanske kommer du i framtiden att vilja tillåta att en enda biljett ägs av flera användare eller grupper? Den här designen framtvingar inte att en biljett måste endast ägas av en enda enhet.
-
Du kan skapa en standardgrupp för varje användare och få biljetter som helt enkelt ägs av antingen en riktig grupp eller en användares standardgrupp.
-
Eller (mitt val) modellera en enhet som fungerar som bas för både användare och grupper och har biljetter som ägs av den enheten.
Här är ett grovt exempel med ditt upplagda schema:
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
)