Распространённые ошибки изменения схемы базы данных PostgreSQL / Николай Самохвалов (Postgres.ai)

Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
HighLoad++ Весна 2021
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем
17 и 18 мая 2021. Москва, Крокус-Экспо
Тезисы и презентация:
www.highload.ru/spring/2021/a...
Один из самых простых и популярных способов «устроить highload на ровном месте» - это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.
В докладе мы подробно разберём ряд типичных ошибок разработчиков, архитекторов и администраторов баз данных, регулярно совершаемых при активной разработке приложений, когда необходимо изменить схему БД - от добавления новых объектов БД, столбцов до рефакторинга и оптимизации существующей схемы.
...
--------
Нашли ошибку в видео? Пишите нам на [e-mail]

[@rin-nas]

Отличный и актуальный доклад! Пересмотрел в 2024 и порадовался за себя. Мы в компании на "оражевой линии" с тонкими клонами, с do-undo-do. Разработчики и тестировщики довольны, как слоны!

[@sergeigavrilov2390]

Хороший доклад. Мне нравится их канал rupostgres. Самохвалов и Космодемьянский светилы в области postgres'а для меня)

[@uthuste]

На каком языке излагал докладчик?

[@timur2887]

язык отличный, все понятно

[@Mark-xp5vo]

Не согласен с 1. IF [NOT] EXISTS может быть полезен. Простой пример. Миграция создает несколько индексов CONCURRENTLY, что нельзя сделать внутри транзакции. Вы должны быть готовы к тому, что миграция по какой-то причине упадет и ее придется перекатывать. Значит миграция должна быть идемпотентна. На помощь приходит CREATE INDEX CONCURRENTLY IF NOT EXISTS. Уверен, что пример не единственный.

[@rin-nas]

При создании таблиц флаг if not exists использовать опасно. Есть риск не создать таблицу, которая задумывалась в миграции. Перед созданием таблицы пишите drop table if exists.

[@user-wn2bd5hj2l]

Я бы отнёс индекс как раз к единственному (или одному из очень немногих) исключений из предлагаемого правила. Но нужно строго определиться с неймингом, исключив возможность повторения названия. Иначе есть риск, что кто-то попытается создать другой по смыслу индекс с существующим именем, но заметит проблему только не получив желаемой оптимизации. А предварительный дроп одноимённого индекса сделает ещё хуже.

[@desontdesont9108]

За знания спасибо, были кейсы, о которых я не знал. Но в примерах SQL запросы написаны маленькими буквами. Созерцал с интересом и отвращением. За снобизм извени.

[@andreyzhidenkov3934]

А в чем проблема писать маленькими? Caps это пережиток прошлого, его использовали когда в тектовых редакторах не было подстветки синтаксиса.

[@constantinegeist1854]

С отвращением смотрю на "извени". Это снобизм, извини.