Почему не используют enum при проектировании БД проекта?

Question

[suhuxa1]

Добрый день!
Я всегда проектировал БД с использованием enum. Весьма полезная вещь в полях, где несколько вариантов. Например: забанен ли? 1 или 0. Админ ли? 1 или 0. И так далее. Но который урок для развития смотрю, везде для таких вещей задают integer. Правильно ли это? Зачем выделять столько памяти, если будет 2 значения? До меня это никак не доходит.

Answer 1

[d-stream]

Моя практика показала, что большинство enum в конце концов становятся референсной таблицей )

Ну разве что исключая совсем уж "внутренние" сущности.

Ну и во многих ЯП enum маппится на int

Comments

[suhuxa1]

референсной таблицей

Объясните, пожалуйста, что это значит?)

[d-stream]

таблица, где живет значение бывшего enum, название в паре тройке ракурсов, признак доступности и т.п.

например если enum был тип контрагента и определялся как 1 - физлицо, 2 - юрлицо, потом добавился 3 - ИП - где-нибудь на "самозанятый ИП" - надоест везде цепляться ифами и кэйсами и захочется поиметь некую таблицу "справочника типов контрагентов", где живет id типа, пара-тройка ракурсов названия ("Физическое лицо", "ФЛ")

Ну а "добывать" значения соответственно

select 
contragent_descr = contragents.descr,
contragent_type = contragent_types.descr,
contragent_type_short = contragent_types.descr_short  
from contragents
inner join contragent_types on contragent_types.contragent_type_id=contragents.contragent_type_id

естественно в таблице контрагентов contragent_type_id - должна ссылаться на contragent_type_id из contragent_types (constraint)

[suhuxa1]

А, понял. Спасибо) Ну а если речь идет о более узких полях, например: "забанен ли?". Тут ведь только 2 варианта: да или нет, и третьего не будет. Как быть в этом случае? Все рано int тип указывать? Не кощунство ли? Причем даже не tinyint люди указывают, а именно int.

[d-stream]

suhuxa1, ну собственно для логических - я использую bit (ms sql), но там есть нюансы

Ну а в остальном tinyint зачастую неудобен, да и как правило современные субд умеют "экономно" хранить маленькие int )

Answer 2

[RidgeA]

Говорю за MySQL - enum все-равно использует 1 или 2 байта, в зависимости от количества вариантов. Так что ничего не мешает завести поле tinyint и хранить значение там - объем занимаемых данных будет такой же.

UPD:
enum под капотом - числа c соответствием набору строк.

Comments

[AlikDex]

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

[AlikDex]

Лентюююй, при нормально спроектированной бд и правильными выбранными типами можно сэкономить процентов 20-30. Если размер бд исчисляется десятками а то и сотнями гигабайт, подумай какая будет разница. + сравнивать 4 байта или 1 байт, как думаешь на нескольких миллионах записей быстрее будет или нет? Добавить к этому много-много тыщ запросов в секунду... Уже молчу про размеры индексов, которые явно не будут влазить в ОЗУ

[Александр Трахимёнок]

Лентюююй, я только одну на 4ТБ. На больше денег не дали.

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

Хватало на 45 дней хранения после всех оптимизаций. Без оптимизаций наверное бы на дней 10 максимум.

[suhuxa1]

В том и дело, что используют даже не tinyint, а именно int

[d-stream]

AlikDex,

при нормально спроектированной бд и правильными выбранными типами можно сэкономить процентов 20-30. Если размер бд исчисляется десятками а то и сотнями гигабайт, подумай какая будет разница. + сравнивать 4 байта или 1 байт, как думаешь на нескольких миллионах записей быстрее будет или нет? Добавить к этому много-много тыщ запросов в секунду... Уже молчу про размеры индексов, которые явно не будут влазить в ОЗУ

Правда если "удобный" размер хранения потребует дополнительных операций преобразования при каждом обращении - просядет производительность)
Поэтому критерий выбора правильности типа данных - это не только размер.
Иногда конечно можно заточиться даже на биты и хранить некий uchar который будет содержать в себе аж 8 булевых сущностей. Но это очень иногда и не в рамках вопроса на тостере.