Моделировать перечисления в TSQL?
Вы можете легко использовать функцию Format () вместо всех приведений только для sql 2012 и выше
SELECT FORMAT(GETDATE(),'hh:mm')
Это, безусловно, лучший способ выполнить необходимое преобразование.
7 ответов
Вы можете посмотреть ответ на этот вопрос . Насколько мне известно, типы перечислений не являются частью SQL Server.
В любом случае, лучше использовать интегральный ( INT , TINYINT , ...) тип для вашего перечисляет, чем строковый тип. Обычно типы перечислений на выбранном вами языке программирования лучше соответствуют целым числам, чем строкам.
В C # по умолчанию каждое значение перечисления соответствует целому числу, начиная с 0. Вы даже можете использовать приведение между ними, так что это допустимый код :
public enum MyEnum
{
FirstEnumValue,
SecondEnumValue
}
...
// Assuming you have opened a SqlDataReader.
MyEnum enumValue = (MyEnum) reader["account_category"];
И LINQtoSQL также поддерживает это. Если у вас есть свойство типа enum, а ваш столбец базы данных имеет целочисленный тип, преобразование выполняется автоматически.
В PostgreSql я просто использую VARCHAR с прикрепленными ограничениями ...
CREATE TABLE movie_clip (
type VARCHAR(40) NULL CHECK(type IN ('trailer', 'commercial')),
);
#=> insert into movie_clip (type) values ('trailer');
INSERT 0 1
#=> insert into movie_clip (type) values ('invalid value');
ERROR: new row for relation "movie_clip" violates check constraint "movie_clip_type_check"
#=> \d movie_clip
....
"movie_clip_type_check" CHECK (type::text = ANY (ARRAY['trailer'::character varying, 'commercial'::character varying]::text[]))
Мне не нравится использовать числовые типы для моделирования ENUM, потому что они недостаточно описательны. С помощью приведенной выше схемы я сразу вижу, какие возможные значения он получает, а также сразу понимаю значение этих значений. Я также получаю безопасность типов, поскольку я не могу вставлять недопустимые значения в этот столбец.
Подробнее об ограничениях для Postgres см. Здесь: http://www.postgresql.org/docs/8.1/static/ddl-constraints.html
Обычно я предпочитаю вызывать параметр @account_category_code и делать его CHAR (3), если имеется только несколько значений перечисления и все они могут быть четко выражены с помощью трех букв. Затем домен принудительно проверяется ограничением. Если имеется более нескольких значений (более 4 или 5), я бы обычно переключался на tinyint / smallint с именем @account_category_type_id и имел для него ссылку на таблицу домена. В моей организации нет жесткого правила, но я считаю, что это хорошо работает.
Иногда тип CHAR более удобен, чем INT - тип char фиксированного размера не занимает много места для хранения, и вы можете видеть "перечисляемые" значения непосредственно в полях базы данных. Никакой разницы со стороны кода, но большой прогресс при работе напрямую с инструментами SQL.
Вы можете создать представление для имитации Enum. См. Эту статью http://www.olegsych.com/2008/07/t4-template-for-generating-sql-view-from-csharp-enumeration/
Будьте предельно осторожны при использовании типа CHAR для enum и вообще избегайте его, если вы хотите, чтобы ваше приложение / база данных выходило на международный уровень.
Не путайте ДАННЫЕ с их представлением: как следует из слов, перечисление - это число, его описание - это совершенно другое дело. Короче говоря, используя переменную / поле CHAR для перечисления, вы привязываете себя к определенному языку для их описания: например, вы можете забыть о интернационализации. Вы можете себе представить, что означает слово «Weltmeisterschaft», на каком языке и - более того - сколько разных способов его написания может быть неправильным?
На самом деле, у (крошечного) int есть обратная сторона значений, которые не являются автоматически описательными: я не говорил, что это идеальное решение!
В SQL вы перечисляете элементы, помещая их в таблицу. Создайте справочную таблицу для категорий ваших учетных записей, и пусть этот параметр принимает первичный ключ для новой таблицы.