аналог enum mysql

[AndreyKl]

аналог enum mysql

Доброго времени суток.

Подскажите пожалуйста, как сделать аналог enum, который есть в mysql ?

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

-~{}~ 11.10.07 22:20:

да.. может кто не в курсе Простите.

в mysql можно описать тип, перечислив его значения, например

table t1 (
access ENUM('public', 'private')
)

А потом можно писать выражения вроде SELECT * FROM t1 WHERE access='public', но нельзя писать SELECT * FROM t1 WHERE access='chto-to drugoe', только public или private.

 

[Mr_Max]

Что тема про Постгрейс и не заметил...
Я думаю чего вопрос странно звучит....

 

[Major]

AndreyKl

в пхп нет перечислений. Можешь использовать массивы или... или я тоже не понял в чем вопрос.

 

[Sad Spirit]

Автор оригинала: AndreyKl
Подскажите пожалуйста, как сделать аналог enum, который есть в mysql ?

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

-~{}~ 11.10.07 22:20:

да.. может кто не в курсе Простите.

в mysql можно описать тип, перечислив его значения, например

table t1 (
access ENUM('public', 'private')
)

А потом можно писать выражения вроде SELECT * FROM t1 WHERE access='public', но нельзя писать SELECT * FROM t1 WHERE access='chto-to drugoe', только public или private.

Ну в версии 8.3 можно будет делать примерно аналогично:

create type access_modifier as enum ('public', 'private');
create table t1 (
    access access_modifier
);

При этом создаётся именно полноценный тип, который можно будет использовать в нескольких таблицах и т.п.

Если же версия 8.3beta1 для тебя недостаточно стабильна, то можно создавать таблицы-справочники.

 

[MiksIr]

Кстати, не очень понимаю назначение enum-ов, хотя раньше "по молодости" их использовал. Теперь сижу и понять не могу - нахрена....
Откройте мне глаза, в чем сокровенный смысл - получить ошибку при вставке чего-то другого, когда вся эта логика переносится в приложение.
Ну если не оффтопить, то такую штуку легко сделать своей функцией и тригером.

 

[Sad Spirit]

Автор оригинала: MiksIr
Кстати, не очень понимаю назначение enum-ов, хотя раньше "по молодости" их использовал. Теперь сижу и понять не могу - нахрена....
Откройте мне глаза, в чем сокровенный смысл - получить ошибку при вставке чего-то другого, когда вся эта логика переносится в приложение.

В чём смысл, чтобы у тебя в базе в поле "пол" нельзя было кроме "мужской" и "женский" вставить ещё и "паркетный"?..

Ну если не оффтопить, то такую штуку легко сделать своей функцией и тригером.

Конечно, но enum'ы в MySQL появились ещё в те времена, когда там ни функций ни триггеров не было, зато была глава в документации "Почему не надо использовать внешние ключи". Ну а в Postgres их щас добавили в кач-ве syntax sugar и для удобства портирования приложений.

 

[AndreyKl]

Спасибо, ясно.

Пока обхожусь булевым типом, ибо у меня поля access и active. Бета для меня не подходит. Не успеет выйти к нужному сроку.

-~{}~ 12.10.07 03:00:

Автор оригинала: Sad Spirit
Конечно, но enum'ы в MySQL появились ещё в те времена, когда там ни функций ни триггеров не было, зато была глава в документации "Почему не надо использовать внешние ключи".

хм, как интересно ). И как же они это объясняли? в смысле, почему же не надо было?

 

[Sad Spirit]

Автор оригинала: AndreyKl
хм, как интересно ). И как же они это объясняли? в смысле, почему же не надо было?

Ну в интернете старая версия документации сохранилась: http://sunsite.univie.ac.at/textbooks/mysql/manual.html#Broken_Foreign_KEY

 

[MiksIr]

Автор оригинала: Sad Spirit
В чём смысл, чтобы у тебя в базе в поле "пол" нельзя было кроме "мужской" и "женский" вставить ещё и "паркетный"?..

Ну я специально обозначил - вся логика в приложении. Гнать данные от пользователя (пусть даже доверенного) в базу и получать ошибку что пришло "паркетный" на уровне SQL ошибки? Это правильно? Ну да, понимаю enum как своеобразный strict, но что бы он был критичный... не понимаю

 

[Sad Spirit]

Автор оригинала: MiksIr
Ну я специально обозначил - вся логика в приложении. Гнать данные от пользователя (пусть даже доверенного) в базу и получать ошибку что пришло "паркетный" на уровне SQL ошибки? Это правильно? Ну да, понимаю enum как своеобразный strict, но что бы он был критичный... не понимаю

Не, ну тут уже спор может быть только про идеологию... Естественно, в приложении проверять надо, но что случится, если вдруг кто-нибудь будет вбивать / редактировать данные через другое приложение, под названием phpPgAdmin?..

К тому же пример с "мужским" / "женским" у меня получился вырожденным, там вряд ли ещё варианты добавляться будут, и делается это всё проще:

create table foo (
    gender char not null check gender in ('м', 'ж')
);

А вот если возможных значений перечислимого типа с десяточек-другой и возможны изменения? Всё равно этот десяточек надо где-то хранить. Как вариант можно хранить в базе (таблица-справочник или enum), а если уж мы там храним, то и проверять правильность (внешним ключом или на уровне проверки типа).

 

[Develar]

>> возможны изменения
смешной вопрос, но как менять значения созданного enum (исключая путь правки системного каталога)?

 

[Sad Spirit]

Автор оригинала: Develar
>> возможны изменения
смешной вопрос, но как менять значения созданного enum (исключая путь правки системного каталога)?

Кстати да, интересный вопрос... ALTER TYPE вроде как с enum'ами не работает.
Ну очевидное решение --- создать новый тип с изменённым списком и сменить на него тип поля таблицы. Вот есть ли что-то более красивое...

 

[Develar]

>> создать новый тип с изменённым списком
легче уж поправить системный каталог, чем делать cascade и как-то потом обратно заливать данные которые были в этом старом столбце. Спасибо, все-таки правильно сказал товарищ в рассылке, лучше и правильнее с точки зрения теории операции dml, чем ddl (http://people.planetpostgresql.org/xzilla/index.php?/archives/320-PostgreSQL-8.3-Features-Enum-Datatype.html).

 

[grigori]

>обратно заливать данные которые были в этом старом столбце
не факт, зависит от объема данных

Я часто логику проверки прописываю в базе, за это я постгрес и люблю. Когда речь о финансовых транзакциях, задача обеспечения целостности данных выходит на 1е место.