Небольшая задача PosgreSQL: вставки ENUM и ENUM
Сегодня самое время поговорить об отличном типе ENUM.
Проблема в следующем, вам нужно классифицировать всех ваших животных (они же звери) по их настроениям в каждый момент времени.
Итак, у вас получилась вот такая простая в изготовлении таблица:
И это хороший первый шаг, но представьте, что вы не в восторге от правописания (имеется в виду субботний вечер) и ваше праздничное настроение подсказывает вставить вместо этого:
Этот вариант «Круто»:
Что ж, это своего рода «круто», но не для вашей базы данных, так как вам понадобится надлежащее «круто», чтобы делать некоторые отчеты о важных настроениях ваших зверей.
Итак, чтобы сделать себя более ответственным за свое настроение, вы создаете эту более ограничительную версию, чтобы иметь только 6 вариантов настроения юмора:
Основная проблема с этим проверочным ограничением заключается в том, что для его повторного использования в других таблицах вам придется каждый раз копировать его вручную. А менять проверочное ограничение очень дорого.
Введите нормализацию. Давайте теперь подумаем о нормальных формах. Да, вы думаете о том, чтобы улучшить величие вашей базы данных, и вы знаете, что нормальные формы — это модные вещи для величественных начинаний.
Таким образом, вы получаете эту таблицу поиска:
Очевидно, вам нужно вставить такие значения, чтобы сохранить жестко определенную таксономию настроения.
И тогда таблица должна быть примерно такой:
В чем проблема с этим? Хорошо, проверьте это в ближайшее время.
Вход в ENUM
Кто-то сказал вам, что вам нужно использовать ENUM, может быть, статью в Medium?. Итак, вы пришли с этим прекрасным типом ENUM, чтобы спасти положение. Ни нормализации, ни идентификаторов, ничего. Просто «развлечение».
Не забудьте обновить таблицу, чтобы она отражала новый тип. Легко, верно?
Проверим под капотом. Что произойдет, если сделать много вставок в уже определенные 3 типа таблиц «beast_humor». Ну, это результаты для первых 3-х вариантов.
Вы можете видеть, что ваша нормализация, какой бы хорошей она ни была, с точки зрения производительности вставки - облом. Кроме того, ограничение проверки не имеет штрафа по сравнению с отсутствием ограничения. В смысле?, это гарантия без влияния на производительность (вау!). Но что происходит с ENUM? Вот оно:
Нет существенной разницы с текстовой проверкой с точки зрения производительности, и ее легче поддерживать. Он дает те же гарантии проверки значений, что и проверочное ограничение, и его можно использовать повторно, следовательно, у него те же преимущества, что и у нормализованной таблицы поиска. В следующей статье (задача PostgreSQL) мы проверим другие возможности ENUM. Итак, следите за обновлениями.
Спасибо Борису Мехиасу за предоставление всей основы для этой статьи. Подпишитесь на него @Tchorix
