Comments 27
ваше предложение сродни тому, как вместо имен переменным давать просто номера, а имена хранить в отдельном словаре
но можно ведь создать отдельную таблицу со статусами
Если у вас меньше 100 статусов — overkill, так как, в случае с отдельной табличкой, будет храниться больше различных счётчиков для оптимистических/пессимистических блокировок, UNIQUE индекс и последовательность.
Нормализация нормализацией, но есть размеры структур СУБД, которые, как и законы физики, преодолеть без паранормальных способностей не представляется возможным.
Но в отдельной табличке можно хранить не только ID+Name, но много чего ещё. Например, когда было добавлено новое значение, кем. Значение можно "упразднить", добавив архивный флаг, тем самым ничего не поломав для исторических данных. Можно ещё добавить полное описание и какие-то другие мета-данные, которые спустя много времени окажутся нужными.
Overkill? Не. Не думаю. По крайней мере, не видно хоть сколько-нибудь значимых потерь. Лично я сталкивался с ситуациями, когда требовалось вывести из употребления старое значение Enum, но его требовалось сохранить для исторических данных. И сколько мне потребовалось воткнуть для этого костылей.
После этого, могу с уверенностью сказать, что тип enum может быть полезен как одноразовое временное решение, но как постоянное.. спасибо, но нет.
Решили что проще делать использовать TINYINT и константы в коде. Если очень критично (или есть желание сделать правильно и красиво), то создаём отдельную таблицу-справочник и внешним ключом контролируем, что там может быть только то, что есть в справочнике.
При добавлении нового значения проблем не заметил вообще
Вообще моветон менять прошлое, имхо
Мне из енамов пока не приходилось ничего удалять, но да, при обновлении большого количества строк, да ещё если в одном запросе, то проблемы будут, но зачем?
Кстати, может будет интересно #PostgreSQL. Ускоряем деплой в семь раз с помощью «многопоточки»
если коротко — как чуваки делают большие update — ранжируют данные на логические части, допустим через ntile, и обновляют частями
как пример — 50к обновлений по 10 тыс. строк — незаметны локи совсем, и… это быстро, т.к. не в одном запросе, а в несколько
и многопоточку сделали на гошечке (реально, в нём из коробки таки это удобно)
короч имейте в виду
pgAdmin 1.22.2 — когда хочется просто мышкой покликать (типа топ 100, фильтрануть по значению из колонки..)
dbForge Studio for PostgreSQL — есть бесплатная версия, плохо дружит с таблицами/колонками «в кавычках».
Просто пробую всё новое иногда, так у меня не остались — navicat, DataGrip, pgAdmin 4
Есть, кстати, интересный проект для поиска ошибок в хранимках и триггерах: plpgsql_check
если про красивые картинки — остановился на DBeaver Community в итоге.
по поводу 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-драйвер.
Но, еще раз, лучший клиент — в консоли. Еще бы там редактировать полегче было…
select unnest(enum_range(null::e_contact_method));
?..или вообще
select enum_range(null::e_contact_method);
кто массивы видит
Postgres Enum