Pull to refresh
26
0
Send message
Спасибо! Мы уже в процессе) Опубликуем ссылки в описании к видео.
Онлайн-трансляция будет в одном зале. Запись будет и в других, но как написано выше, не все спикеры хотят, чтобы их выступления были в сети.
Не все спикеры хотят записываться или попадать в онлайн-трансляцию. Это бывает и на DevGamm, и на других конференциях =) К тому же, есть контент который просто бессмысленно записывать. Например, мастер-классы.
Трансляция будет, но только одного зала. Так что если есть возможность, то лучше приходите =)
Запись будет, но не всех докладов. Так что если есть возможность, то лучше приходите =)
Привет! Наши разработчики постоянно работают с продакшеном, и базами в том числе. Деплой и разработка все вместе контролируют и обмениваются статистикой. Также нет проблем и с админами. Наверное, бывают разные случаи, но в целом все работает именно так.
Всего три часа на самолете. А многие спикеры прилетят выступать из Америки. Так что приезжайте, не пожалеете)
В документации на ALTER TYPE ничего не написано про блокировки. И здравый смысл подсказывает, что нет никакой необходимости блокировать какие-либо таблицы при добавлении нового значения в ENUM. Вот при удалении значения, да, блокировки могут понадобится.
Да, можно было бы сохранить куда-то. Но нашем случае это не нужно.
Тут дело в том, рассматриваем ли мы добавление нового типа как штатную операцию, или как некое нештатное действие, требующее митингов, согласований, привлечения девопсов и т. д.
Да, за счет типа меньшего размера в одном столбце трудно получить выигрыш. Нужно несколько таких столбцов.

Что касается производительности, то я предположу, что для значений в рамках одного машинного слова она будет одинаковая.
Смысл перехода от varchar к enum был в том, чтобы ограничить возможные значения type. Заодно, как бонус, получить уменьшение индекса.

Это можно было бы сделать и так, как вы говорите — вынести список возможных типов в отдельную таблицу. Но такой вариант, очевидно, сложнее. Он требует дополнительных действий и на вставке нового кота (сперва нужно получить id типа по имени типа), и на чтении котов (нужно делать join).

ENUM покрывает наши потребности полностью, и делает это более простым способом. Принцип KISS.

Ну и, опять же, декларация намерений. Создавая таблицу с типами мы декларируем, что типы будут меняться — можно добавлять новые и т. д. Создавая ENUM, мы декларируем, что список типов статичен, и меняться не будет.

insert в таблицу — штатная операция. alter type — нештатная операция. То есть мы подчеркиваем, что таких операций не хотим.
Мы так делаем. Но будем рады, если вы расскажете, почему это плохо)
Если мне понадобится добавить еще один тип, то я сделаю миграцию ALTER TYPE cat_type ADD VALUE ‘some new value’;

Атрибуты для типа за 3 года эксплуатации не понадобились. А иначе мы бы сделали по-другому.

В целом лучше использовать простые вещи, когда они подходят. А сложные брать когда не подходят простые.
Подразумевается, что список типов котов статичный. Добавлять в него новые типы не нужно.

Контроль целостности обеспечивается самим типом ENUM.

Ну а экономия за счет 2-х байтов smallint вместо 4-х байтов enum, как показал эксперимент, все равно ничего не дает.
Подразумевается, что список типов котов статичный. В него не будут добавляться новые типы. Так что это ближе к перечисляемому типу, чем к словарю.
Между ними нет разницы ни по производительности, ни по занимаемой памяти.

Разница только в декларации намерений. Используя TEXT, мы декларируем намерение хранить «длинные тексты». А используя varchar, мы декларируем намерение хранить «короткие строки». Причем разница между «длинным» и «коротким» субъективна.

Это просто дело вкуса.
Да, партицирование у нас есть, и там много интересного. Как-нибудь расскажем про это)

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity