또 다른 접근 방식은 각 잠재적 리소스 유형에 대한 열을 포함하는 연결 테이블을 만드는 것입니다. 귀하의 예에서 두 가지 기존 소유자 유형 각각에는 자체 테이블이 있습니다 (참조 할 항목이 있음을 의미 함). 항상 이런 경우라면 다음과 같이 할 수 있습니다.
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_type을 포함하는 것이 좋습니다.
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이 잘못되면 미안합니다. 그냥 함께 던졌습니다.