
Читая немного о MySQL перечисление, я предполагаю, что ближайшим эквивалентом будет простое ограничение проверки.
CREATE TABLE sizes (
name VARCHAR2(10) CHECK( name IN ('small','medium','large') )
);
но это не позволяет ссылаться на значение по индексу. Также возможны более сложные отношения внешнего ключа
CREATE TABLE valid_names (
name_id NUMBER PRIMARY KEY,
name_str VARCHAR2(10)
);
INSERT INTO valid_sizes VALUES( 1, 'small' );
INSERT INTO valid_sizes VALUES( 2, 'medium' );
INSERT INTO valid_sizes VALUES( 3, 'large' );
CREATE TABLE sizes (
name_id NUMBER REFERENCES valid_names( name_id )
);
CREATE VIEW vw_sizes
AS
SELECT a.name_id name, <<other columns from the sizes table>>
FROM valid_sizes a,
sizes b
WHERE a.name_id = b.name_id
Пока вы работаете через представление, может показаться, что вы можете достаточно хорошо воспроизвести функциональность.
Теперь, если вы допускаете решения PL / SQL, вы можете создавать пользовательские типы объектов, которые могут включать логику для ограничения набора значений, которые они могут содержать, и иметь методы для получения идентификаторов и значений и т. д.
Не уверен, что это ближе, но я подумал, что брошу его туда.
Да, это ближе, и это решение, которое я сейчас использую, но просто хотел, чтобы не было лучшего способа
К сожалению, мне нужно поддерживать 3 разные базы данных, поэтому я не могу использовать PL / SQL или придерживаться только приятной функции MySQL.
Хотя это не совсем идеальное решение, если не считать добавления новых функций Oracle, это единственный способ сделать это (около 2008 г.).
Теперь, почти три года спустя - это все еще рекомендуемая практика с последней и лучшей версией Oracle 11g?
@ User272735 - Да, это все еще подходящий способ моделирования такого рода ограничений в 11.2.
@JustinCave Можно ли иметь набор констант из пакета в списке допустимых значений?
@ChetterHummin - я так не думаю, нет. Вы можете заставить пакет создать коллекцию допустимых значений при инициализации, прочитав данные из таблицы поиска.
По этой ссылке вы можете найти альтернативное решение / обходной путь для Oracle, вдохновленный перечислениями языка C: http://www.petefinnigan.com/weblog/archives/00001246.htm
Короче говоря, Пит предлагает определить некоторые целочисленные константы и использовать SUBTYPE для их определения:
RED constant number(1):=1;
GREEN constant number(1):=2;
BLUE constant number(1):=3;
YELLOW constant number(1):=4;
subtype COLORS is binary_integer range 1..4;
После этого вы можете объявлять переменные, передавать параметры и возвращать значения из функций и т. д. С типом COLORS.
это явно для PL / SQL (это в заголовке статьи), и OP конкретно сказал, что ему нужен SQL, а не PL / SQL. В комментариях к ответу Джастина также упоминается, что он должен работать в нескольких базах данных и не может использовать специфические для Oracle функции.
Как разработчик, который начал с MySQL и перешел на Oracle, я каждый день удивляюсь, что в корпоративном продукте отсутствует набор функций бесплатного продукта баз данных. Интересно, есть ли четкое обоснование производительности, почему такие типы недоступны в MSSQL или PL / SQL?
@JosephLust В чем разница между перечислением MySQL и Oracle, имеющим varchar2 с проверочным ограничением? На практике они кажутся одним и тем же, но с дополнительным преимуществом, заключающимся в том, что это не новый тип данных. Длинный список типов данных столбцов в MySQL довольно смехотворен - их наличие требует затрат, по крайней мере, затрат на обслуживание.
@ fool4jesus Основное отличие - требования к хранилищу + размер индекса. ENUM позволяет хранить 255 произвольных именованных значений в 1 байте. С varchar2 вам нужно X байтов для каждой строки в зависимости от имени. (Или вместо этого используйте отдельную таблицу поиска с VIEW или JOIN, чтобы увидеть имена, упомянутые в первом ответе).
@JosephLust в качестве объяснения ОТ может заключаться в том, что дорогие продукты не (обязательно) лучшего качества, а только лучше продаются или продаются.
Почему бы не использовать ограничение для столбца? Он будет делать то же самое:
ALTER TABLE x ADD CONSTRAINT проверка ограничения_размера (x_size in ('small', 'medium', 'large'))
У вас есть Enums в MySQL, они очень полезны :) В любом случае спасибо!