PostgrSQL — Какой тип данных лучше использовать для статусов, типы объекта и т.д?

Question

[Дилик Пулатов]

Часто использую кастомные типы для статусов и т.д

CREATE TYPE order_status AS ENUM ('new', 'open', 'closed');

Не давно знакомы программисты предлагали использовать TINYINT для таких полей.
Я не так часто меняю такие списки. Поэтому для меня достаточно кастомные типы.
Но после того как предлагали лучше использовать TINYINT я начал искать в гугл плюсы и минусы эти типы.
Пока толком ничего не нашел. Где-то говорят типы ENUM это зло. но ENUM тип в MySQL есть. А в PostgrSQL это просто кастомные типы.
Важно чтобы потом проблема в производительность не было. Для меня важен скорость CRUD запросов.
В чем разница между этих типов? Какие плюсы и минусы есть?

Comments

[Иван Спасов]

Не являюсь экспертом в субд, бэкендером, но кажется это какая-то экономия на спичках (или у вас HL проект?, тогда советуйтесь внутри команды, у вас явно есть техлид или DBas), под описанную задачу вполне подходим enum, в чем проблемы при его использовании ?, в чем ENUM зло ?

Я слышу фразу "enum - зло" уже лет 10, как только связался с разработкой, но на вопрос "почему?" - никто внятно и достаточно емко не отвечает.

[nApoBo3]

ИМХО могут быть проблемы с различными orm.
Я бы использовал tinyint или ему подобные типы для постоянных данных и text для временных данных.

Answer 1

[ky0]

Вкусовщина.

Answer 2

[Vitsliputsli]

В чем разница между этих типов? Какие плюсы и минусы есть?

По факту у вас enum, и тогда вопрос как его хранить, как enum или как число, будет звучать: где реализовывать enum в коде или в БД. Реализация в коде позволит валидировать этот enum на уровне приложения без дополнительных запросов к БД, в противном случае все это ложится на СУБД. В остальном разницы нет.
Т.к. БД всегда узкое место, то я бы реализовал это в коде, но есть адепты считающие, что все нужно пихать в БД.