SQL Server эквивалентен типу данных MySQL enum?

132

Есть ли у SQL Server 2008 такой тип данных, как у MySQL enum?

155

Это не так. Есть неопределенный эквивалент:

mycol VARCHAR(10) NOT NULL CHECK (mycol IN('Useful', 'Useless', 'Unknown'))

— хаос
источник

10

Почему бы не использовать таблицу, которая определяет допустимые значения, а затем вместо этого использовать ограничение внешнего ключа?

— Elaskanator 05

@Elaskanator Я бы сказал, что это наиболее точно отвечает на прямой OP, в то время как лучшим решением для него, вероятно, является использование внешней таблицы FK +.

— userfuser

Спасибо @Elaskanator за то, что напомнили мне об очевидном ... нормализовать данные, и перечисление перестает существовать.

— Эндрю

88

Лучшее решение, которое я нашел в этом, - создать таблицу поиска с возможными значениями в качестве первичного ключа и создать внешний ключ для таблицы поиска.

— user1431422
источник

13

Лучшее решение с точки зрения ремонтопригодности, чем проверочное ограничение, показанное выше.

— HLGEM

21

Это лучшее решение, чем Enums - в том числе и в MySQL.

— ypercubeᵀᴹ

2

@ypercube Почему это лучше и для MySQL?

— BenR

4

@BenRecord Есть несколько проблем с перечислениями MySQL: 8 причин, почему тип данных ENUM в MySQL - зло . Я не согласен на 100%, что это зло, но вы должны быть очень осторожны при их использовании.

— ypercubeᵀᴹ

1

@BenR также, если я правильно помню, в нестрогом режиме с MySQL недопустимое перечисление может быть вставлено как NULL. Каким бы ни было условие, у моей предыдущей команды были проблемы с тем, что перечисление MySQL не вставлялось и не выходило из строя, когда значение не было указано в списке значений. Ограничение внешнего ключа в таблице поиска приведет к сбою. Я согласен, что справочная таблица лучше для MySQL.

— Джим Шуберт

4

ИМХО таблицы поиска - это путь со ссылочной целостностью. Но только в том случае, если вы избегаете "зловещих магических чисел", следуя примеру, подобному этому: сгенерировать перечисление из таблицы поиска базы данных с помощью T4

Радоваться, веселиться!

— Джони Адамит
источник

2

CREATE FUNCTION ActionState_Preassigned()
RETURNS tinyint
AS
BEGIN
    RETURN 0
END

GO

CREATE FUNCTION ActionState_Unassigned()
RETURNS tinyint
AS
BEGIN
    RETURN 1
END

-- etc...

Если производительность имеет значение, по-прежнему используйте жесткие значения.

— Димитриос Стаикос
источник

1

Обнаружил этот интересный подход, когда хотел реализовать перечисления в SQL Server.

Подход, упомянутый ниже в ссылке, довольно убедителен, учитывая, что все ваши потребности в перечислении базы данных могут быть удовлетворены с помощью двух центральных таблиц.

http://blog.sqlauthority.com/2010/03/22/sql-server-enumerations-in-relational-database-best-practice/

— user_v
источник

8

Это разновидность анти-шаблона, известного как «одна истинная (справочная) таблица». Правильный подход состоит в том, чтобы иметь отдельную таблицу для каждого типа перечисления и использовать внешние ключи (если вам вообще нужен поиск, что может не относиться к «чистым» перечислениям).

— Бранко Димитриевич

2

Комментарии на связанной странице являются хорошей резервной копией для использования отдельных таблиц для каждого «перечисления», а не того, что указано в этом ответе

— skia.heliou

4

Довольно забавно, как большинство людей справедливо возражают против такого дизайна, но автор называет свою статью «Лучшая практика».

— underscore_d