Как стать автором
Обновить

Комментарии 27

Лично мне излишним в своё время при миграции с MySQL показалось не сами перечисления как таковые (в мускуле они как раз были), а обход строгой типизации постгри тем или иным способом. На уровне ORM просто не получилось, а лезть в «хранимки» очень не хотелось, собственно одна из целей перехода на постгри было избавление от них.
Возможно, что-то не так понял, но можно ведь создать отдельную таблицу со статусами, связать их ключами, и сделать вьюху, если прямо хочется смотреть на данные глазками. И нормализация, и ещё меньше места должно занимать.
запись заметно усложнится
тут про немного другую задачу.
ваше предложение сродни тому, как вместо имен переменным давать просто номера, а имена хранить в отдельном словаре
в свинге тоже не все так однозначно
хм… а я не тут это писал. это на другой коммент ответ
но можно ведь создать отдельную таблицу со статусами

Если у вас меньше 100 статусов — overkill, так как, в случае с отдельной табличкой, будет храниться больше различных счётчиков для оптимистических/пессимистических блокировок, UNIQUE индекс и последовательность.


Нормализация нормализацией, но есть размеры структур СУБД, которые, как и законы физики, преодолеть без паранормальных способностей не представляется возможным.

Но в отдельной табличке можно хранить не только ID+Name, но много чего ещё. Например, когда было добавлено новое значение, кем. Значение можно "упразднить", добавив архивный флаг, тем самым ничего не поломав для исторических данных. Можно ещё добавить полное описание и какие-то другие мета-данные, которые спустя много времени окажутся нужными.

Overkill? Не. Не думаю. По крайней мере, не видно хоть сколько-нибудь значимых потерь. Лично я сталкивался с ситуациями, когда требовалось вывести из употребления старое значение Enum, но его требовалось сохранить для исторических данных. И сколько мне потребовалось воткнуть для этого костылей.

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

В своё время, в MySQL активно использовали тип enum, всем хорош: и места занимает, и контроль данных, и визуально сразу понятно, что за значение. Но стоит захотеть добавить или убрать значение, то надо делать ALTER TABLE, который на миллионах записях мог довольно долго выполняться.
Решили что проще делать использовать TINYINT и константы в коде. Если очень критично (или есть желание сделать правильно и красиво), то создаём отдельную таблицу-справочник и внешним ключом контролируем, что там может быть только то, что есть в справочнике.
Хорошо, что у нас postgres
При добавлении нового значения проблем не заметил вообще
НЛО прилетело и опубликовало эту надпись здесь
С тиниинтом проще было бы?
Вообще моветон менять прошлое, имхо
Мне из енамов пока не приходилось ничего удалять, но да, при обновлении большого количества строк, да ещё если в одном запросе, то проблемы будут, но зачем?
НЛО прилетело и опубликовало эту надпись здесь

Кстати, может будет интересно #PostgreSQL. Ускоряем деплой в семь раз с помощью «многопоточки»


если коротко — как чуваки делают большие update — ранжируют данные на логические части, допустим через ntile, и обновляют частями
как пример — 50к обновлений по 10 тыс. строк — незаметны локи совсем, и… это быстро, т.к. не в одном запросе, а в несколько
и многопоточку сделали на гошечке (реально, в нём из коробки таки это удобно)


короч имейте в виду

НЛО прилетело и опубликовало эту надпись здесь
Спасибо, очень дельное замечание!

У нас есть пара мест с подобным применением
И колонки, естественно, числовые
Конечно можно заюзать массив… строк, енамов (не пробовал), гуидов, но… это уже будет не так удобно, как просто число
Не поделитесь, каким инструментарием пользуетесь для работы с postgres? Это SQL Tabs у вас на скриншоте 4 и 5?
SQL Tabs v0.18.0 — посмотрите, что он умеет. Как правило его юзаю для написания запросов, когда нужно именно писать запросы, смотреть план, исполнять несколько запросов разом

pgAdmin 1.22.2 — когда хочется просто мышкой покликать (типа топ 100, фильтрануть по значению из колонки..)

dbForge Studio for PostgreSQL — есть бесплатная версия, плохо дружит с таблицами/колонками «в кавычках».

Просто пробую всё новое иногда, так у меня не остались — navicat, DataGrip, pgAdmin 4
pgAdmin 3 (pgAdmin 1.22.2) очень доволен, стабильнее и быстрее pgAdmin 4. pgAdmin 4 способен привести к взаимоблокировке при выполнении простых скриптов, перемудрили с многопоточностью. А вот что пока не удаётся найти, так это адекватный дебаггер.

Есть, кстати, интересный проект для поиска ошибок в хранимках и триггерах: plpgsql_check
Лучше всего — psql :-)
если про красивые картинки — остановился на DBeaver Community в итоге.
psql, я уж спецом его не написал ))

по поводу DBeaver пока только минусы:
1. слишком монструозен
2. требует яву! Ну не было её у меня до этого
3. чтобы качнуть дрова для оракла — потребовалась рега на oracle.com (хотя для пг не запросил и скачал молча)
4. Коннектит именно к БД, т.е. с лёту не увидел, как именно получить список всех бд в дереве объектов

Хотя… есть плюсик — всё же комьюнити версия бесплатна и очень мне помогла в коннекте к продовской чужой бд
слишком монструозен

Эта монструозность проявляется только на старте.

требует яву!

Есть дистрибутивы с предустановленной jre, тупо распаковать архив и запустить.

потребовалась рега на oracle.com

Это не вина бобра. Ораклового драйвера нет в публичных репозиториях.

Коннектит именно к БД

Опять же это ограничение не бобровое. It is not possible to access more than one database per connection.

Можно использовать галочку «Show non-default databases» диалоге настройки соединения, чтобы видеть все имеющиеся БД на сервере. А также «Switch default database on access» для переподключения к другой базе при необходимости. Но проще настроить несколько подключений к разным БД.
Монструозен? Странно — для меня это почти стоп-фактор по жизни, но тут я этого не заметил/замечаю. ява — это большой минус, согласен.
Дрова для Оракла? У меня ничего такого не было нужно. Или имеется в виду коннектор к ДБ?

Список дб получить нетрудно в psql :-)

Да, должно быть это был коннектор, я не уверен в верности терминологии в данной ситуации

я этого не заметил/замечаю

Не соглашусь, этого сложно просто не заметить. Не обращать внимания — да, но не замечать невозможно. Не будете же спорить, что запускается бобёр куда как медленнее, нежели pgadmin, например.

Дрова для Оракла? У меня ничего такого не было нужно.

Имелся ввиду jdbc-драйвер.
Специально засек: меньше 10 секунд. Учитывая, что я не перегружаюсь неделями — меня это вполне устраивает. pgadmin мне понравился меньше, прежде всего возможностями работы с результатами запроса. Еще я часто подключаюсь к mysql и maria тоже. И pgadmin у меня постоянно вылетал.

Но, еще раз, лучший клиент — в консоли. Еще бы там редактировать полегче было…
4. Просмотр всех возможных значений:
select unnest(enum_range(null::e_contact_method));
?..
или вообще
select enum_range(null::e_contact_method);
кто массивы видит
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории