Есть ли способ обеспечить набор значений для столбца таблицы базы данных?

Question

У меня есть таблица, в которой в одном из столбцов я бы указывал тип объекта. Объект может быть только трех типов - заголовок, изображение или комментарий, поэтому я хочу убедиться, что столбец таблицы должен принимать только одна из этих трех строк. Есть ли способ поставить это ограничение в MS SQL Server 2008?

Редактировать: - добавили диаграмму БД, чтобы получить советы по улучшению дизайна.

Дизайн: - 1) На раскадровке есть несколько слайдов, каждый слайд может содержать одну или несколько подписей или изображений.

2) Каждая раскадровка может иметь одного или нескольких авторов и ноль или более рецензентов.

3) Каждый из объектов изображения, слайда и подписи (возможно, больше объектов появится позже, например, аудио и т. Д.) Может иметь комментарии к ним. Эти комментарии могут быть предоставлены авторами или рецензентами. Для хранения комментариев я создал таблицу комментариев.

4) Необходимо запомнить порядок слайдов и порядок изображений в слайде, для чего я использую поля слайдов и номеров изображений.

5) Поскольку комментарий может быть задан для любого объекта, мне нужно было иметь глобальный идентификатор для каждого объекта, поскольку их ссылки будут храниться в таблице комментариев. Для сохранения глобального идентификатора все поля, заканчивающиеся на имя GID - это уникальные идентификаторы, генерируемые с использованием Default: NEWID ().

Пожалуйста, предложите улучшения для этого дизайна БД.

Answer 1

Вот как вы делаете это с проверочными ограничениями:

create table #tableWithConstrainedColumn (
    constrainThis varchar(20)
)

ALTER TABLE #tableWithConstrainedColumn ADD CONSTRAINT TempCheck
    CHECK (constrainThis in ('caption', 'image', 'comment'))

-- this statement will succeed
insert into #tableWithConstrainedColumn
select 'caption'
-- this statement will fail
insert into #tableWithConstrainedColumn
select 'captions'

drop table #tableWithConstrainedColumn

Вы также можете определить тип данных, но я бы не рекомендовал делать это так:Как только что рекомендовал @Widor, для этого лучше всего использовать внешние ключи.

Answer 2

Звучит как работа для Foreign Keys ?

Answer 3

Ага, в этом случае природа проблемы иная! Отсюда мой второй ответ здесь.

Я признаю, что не на 100% уверен, что это «лучшее» решение. Я думаю, что то, как вы планируете запрашивать эти данные, в определенной степени будет определять способ их хранения.

Из дополнительной информации, которую вы разместили, я бы предложил удалить таблицу Comment, чтобы в * хранилась информация о комментариях. Потерять поля ObjID, ObjType и, возможно, usertype тоже - разве это не должно быть в таблице User?

Затем я бы предложил добавить в вашу схему три новые таблицы: SlideComment, CaptionComment и ImageComment, каждая из которых содержит всего два поля:
Один для хранения CommentId (который будет иметь FK для таблицы Comment), а другой для хранения слайдов, надписей или изображений GID в зависимости от ситуации.

Итак, эти новые таблицы используются исключительно для присоединения Comment к какой бы сущности они не были созданы. Это должно позволить вам запрашивать данные так, как вы хотите, не беспокоясь о том, к какому «объекту» они относятся.

Answer 4

Используйте проверку ограничений или вызовите ПЕРЕД ВСТАВКОЙ, ОБНОВИТЕ и запишите эту проверку в it.