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

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

Комментарии • 8

  • @rin-nas

    Отличный и актуальный доклад!

  • @sergeigavrilov2390
    @sergeigavrilov2390 3 года назад +11

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

  • @Mark-xp5vo

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

  • @desontdesont9108
    @desontdesont9108 2 года назад +2

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