Не все спикеры хотят записываться или попадать в онлайн-трансляцию. Это бывает и на DevGamm, и на других конференциях =) К тому же, есть контент который просто бессмысленно записывать. Например, мастер-классы.
Привет! Наши разработчики постоянно работают с продакшеном, и базами в том числе. Деплой и разработка все вместе контролируют и обмениваются статистикой. Также нет проблем и с админами. Наверное, бывают разные случаи, но в целом все работает именно так.
В документации на ALTER TYPE ничего не написано про блокировки. И здравый смысл подсказывает, что нет никакой необходимости блокировать какие-либо таблицы при добавлении нового значения в ENUM. Вот при удалении значения, да, блокировки могут понадобится.
Тут дело в том, рассматриваем ли мы добавление нового типа как штатную операцию, или как некое нештатное действие, требующее митингов, согласований, привлечения девопсов и т. д.
Смысл перехода от varchar к enum был в том, чтобы ограничить возможные значения type. Заодно, как бонус, получить уменьшение индекса.
Это можно было бы сделать и так, как вы говорите — вынести список возможных типов в отдельную таблицу. Но такой вариант, очевидно, сложнее. Он требует дополнительных действий и на вставке нового кота (сперва нужно получить id типа по имени типа), и на чтении котов (нужно делать join).
ENUM покрывает наши потребности полностью, и делает это более простым способом. Принцип KISS.
Ну и, опять же, декларация намерений. Создавая таблицу с типами мы декларируем, что типы будут меняться — можно добавлять новые и т. д. Создавая ENUM, мы декларируем, что список типов статичен, и меняться не будет.
insert в таблицу — штатная операция. alter type — нештатная операция. То есть мы подчеркиваем, что таких операций не хотим.
Между ними нет разницы ни по производительности, ни по занимаемой памяти.
Разница только в декларации намерений. Используя TEXT, мы декларируем намерение хранить «длинные тексты». А используя varchar, мы декларируем намерение хранить «короткие строки». Причем разница между «длинным» и «коротким» субъективна.
о чем расскажут на
«4C: Санкт-Петербург»
о чем расскажут на
«4C: Санкт-Петербург»
о чем расскажут на
«4C: Санкт-Петербург»
о чем расскажут на
«4C: Санкт-Петербург»
о чем расскажут на
«4C: Санкт-Петербург»
Что касается производительности, то я предположу, что для значений в рамках одного машинного слова она будет одинаковая.
Это можно было бы сделать и так, как вы говорите — вынести список возможных типов в отдельную таблицу. Но такой вариант, очевидно, сложнее. Он требует дополнительных действий и на вставке нового кота (сперва нужно получить id типа по имени типа), и на чтении котов (нужно делать join).
ENUM покрывает наши потребности полностью, и делает это более простым способом. Принцип KISS.
Ну и, опять же, декларация намерений. Создавая таблицу с типами мы декларируем, что типы будут меняться — можно добавлять новые и т. д. Создавая ENUM, мы декларируем, что список типов статичен, и меняться не будет.
insert в таблицу — штатная операция. alter type — нештатная операция. То есть мы подчеркиваем, что таких операций не хотим.
Атрибуты для типа за 3 года эксплуатации не понадобились. А иначе мы бы сделали по-другому.
В целом лучше использовать простые вещи, когда они подходят. А сложные брать когда не подходят простые.
Контроль целостности обеспечивается самим типом ENUM.
Ну а экономия за счет 2-х байтов smallint вместо 4-х байтов enum, как показал эксперимент, все равно ничего не дает.
Разница только в декларации намерений. Используя TEXT, мы декларируем намерение хранить «длинные тексты». А используя varchar, мы декларируем намерение хранить «короткие строки». Причем разница между «длинным» и «коротким» субъективна.
Это просто дело вкуса.