Вариант 2 - , а не - хорошее решение для реляционной базы данных.Он называется полиморфными ассоциациями (как упомянуто @Daniel Vassallo) и нарушает фундаментальное определение отношения.
Например, предположим, что у вас есть ResourceId 1234 в двух разных строках.Они представляют один и тот же ресурс?Это зависит от того, является ли CommentTypeId одинаковым в этих двух строках.Это нарушает концепцию типа в отношении.См. SQL и реляционную теорию от CJ Date для получения более подробной информации.
Еще один признак того, что это неправильный дизайн, заключается в том, что вы не можете объявить ограничение внешнего ключа для ResourceId, поскольку оно может указывать налюбая из нескольких таблиц.Если вы попытаетесь навязать ссылочную целостность с помощью триггеров или чего-то еще, вы будете переписывать триггер каждый раз, когда добавляете новый тип комментируемого ресурса.
Я бы решил это с помощью решения, которое кратко упоминает @mdma (но потомигнорирует):
CREATE TABLE Commentable (
ResourceId INT NOT NULL IDENTITY,
ResourceType INT NOT NULL,
PRIMARY KEY (ResourceId, ResourceType)
);
CREATE TABLE Documents (
ResourceId INT NOT NULL,
ResourceType INT NOT NULL CHECK (ResourceType = 1),
FOREIGN KEY (ResourceId, ResourceType) REFERENCES Commentable
);
CREATE TABLE Projects (
ResourceId INT NOT NULL,
ResourceType INT NOT NULL CHECK (ResourceType = 2),
FOREIGN KEY (ResourceId, ResourceType) REFERENCES Commentable
);
Теперь у каждого типа ресурса есть своя собственная таблица, но последовательный первичный ключ уникально выделяется Commentable.Заданное значение первичного ключа может использоваться только одним типом ресурса.
CREATE TABLE Comments (
CommentId INT IDENTITY PRIMARY KEY,
ResourceId INT NOT NULL,
ResourceType INT NOT NULL,
FOREIGN KEY (ResourceId, ResourceType) REFERENCES Commentable
);
Теперь Комментарии ссылаются на комментируемые ресурсы, с соблюдением ссылочной целостности.Данный комментарий может ссылаться только на один тип ресурса.Нет никакой вероятности аномалий или конфликтующих идентификаторов ресурсов.
Более подробно о полиморфных ассоциациях я расскажу в своей презентации Практические объектно-ориентированные модели в SQL и в моей книге Антипаттерны SQL .