Я создаю таблицу, которая выглядит примерно так.
CREATE TABLE packages
(
productCode char(2)
, name nvarchar(100)
, ...
)
Как убедиться, что productCode всегда имеет одно из двух значений: XJ или XD?


ALTER TABLE packages
ADD CONSTRAINT constraintname CHECK (productCode in ('XJ', 'XD'))
Я бы посоветовал использовать справочную таблицу для будущего расширения. Вставить еще одну строку в таблицу намного проще, чем выяснить, как восстановить ограничение.
Да, в этом случае я использую ЯГНИ. :-)
Это работает в Oracle, MySQL и т. д.? Я использую MS SQL Server 2000, но если решение довольно стандартное, имеет смысл отметить это и удалить тег sqlserver.
Оракул, да. Mysql - думаю, что нет. Mysql, похоже, хочет наложить ограничение на столбец вместо проверки допустимости строки.
MySQL не поддерживает ограничения CHECK. Они могут делать нечто подобное со своим проприетарным типом данных ENUM.
Либо сделайте его иностранный ключ в поисковой таблице, либо добавьте проверить ограничение для его принудительного применения.
CREATE TABLE packages
(
productCode char(2)
, name nvarchar(100)
, ...
,CONSTRAINT productCode CHECK (productCode in ('XJ','XD') )
)
Разве первый «productCode» не должен быть именем ограничения вместо имени столбца?
Это - конечно, вы можете назвать это как угодно, но если я помещаю проверочное ограничение для одного столбца, я обычно просто использую имя столбца.
Здорово. Я всегда предполагал, что ограничение не может иметь то же имя, что и столбец в той же таблице.
В этом случае кажется, что набор значений для ProductCode довольно ограничен, и вы не ожидаете, что он будет расти в обозримом будущем, поэтому я склонен согласиться с ответами checkconstraint. Однако в большинстве случаев я бы реализовал решение с внешним ключом, как было предложено г-ном Грантом, поскольку у моих клиентов есть неприятная привычка менять свое мнение (а также требования) примерно раз в день. В этой ситуации мой срок истекает, потому что версию FK легче поддерживать.
Глядя на этот вопрос 7 лет спустя, если бы я повторил это снова, я бы добавил таблицу и внешний ключ. Полезно для документации "что означает XJ?" хранилище данных и лучшая переносимость между СУБД.