Как выполнить контроль версий процедур, представлений и функций в Postgres sql

Question

Я хочу сделать контроль версий моей базы данных.

В настоящее время я управляю своими интерфейсными приложениями через git, однако я создаю свою базу данных и хотел бы иметь версии своих таблиц, функций и процедур, как я могу это сделать для базы данных? То есть я внесу изменение в функцию, но я хотел бы сохранить предыдущую, которую я выполнял, на случай, если возникнет какая-либо проблема, я могу снова поставить предыдущую.

Answer 1

Основные инструменты для управления версиями структуры базы данных, включая дополнительную миграцию данных:

• Flyway
• Liquibase

Однако специфика вашего вопроса выходит за рамки того, что предлагают существующие инструменты сегодня.

Если вам необходимо иметь две или более версии какого-либо объекта в базе данных для параллельного использования (например, пошаговое руководство)перенос таблиц, триггеров и т. д.) вам лучше использовать:

1. схему именования, встроенную в объекты, например my_cool_function_v2 против my_cool_function_v3

... или:

использовать разные схемы базы данных для каждой основной версии (если вы придерживаетесь подхода семантической версии), например, CREATE FUNCTION my_schema_v2.my_cool_function не будет конфликтовать с my_schema_v1.my_cool_function

В обоих случаях вы обычно имеетеуправлять ссылками на более новую версию, где хотел.Для второго подхода это может быть дополнительно упрощено с помощью схемы search_path, которую можно изменить, чтобы она предпочла новую схему, содержащую новые версии объектов, например:

SET search_path TO my_schema_v2, my_schema_v1, public;

динамически (полезно для тестирования в действующей системе без влияния на реальные приложения / пользователей) и, как только вы будете уверены, что основы установлены, включите его в конфигурацию PostgreSQL (postgresql.conf), чтобы новая схема стала стандартной для каждого нового соединения:

search_path = 'my_schema_v2, my_schema_v1, public'

После того, как вы перенесли все новые объекты и все работает нормально, вы можете удалить старый my_schema_v1 из search_path, а также DROP ... CASCADE, чтобы удалить все старые объекты водин раз.

Однако один недостаток подхода к схеме заключается в том, что если вы всегда создаете все объекты (функции, триггеры, таблицы, ...) во всех схемах, вы потеряете их преимущества в сочетании сsearch_path.Поэтому я бы создал разные схемы для разных объектов, например, data_v1 для данных (таблицы, индексы, ...) и func_v1 для других вещей (функций, процедур, ...).Таким образом, вы можете развивать структуру независимо от данных, но в то же время вы можете также начать развивать структуру таблиц и автоматически извлекать выгоду из исправлений / улучшений функций, а также проверять, совместимы ли изменения с прямой пересылкой.