Практика Исправления схем

Question

У нас есть схема в Postgres, и мы хотим внедрить хороший метод применения исправлений схемы.

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

У нас также есть несколько файлов "исправлений", которые соответствуют версиям нашей системы.т.е.исправления /1.0.0.sql, исправления/1.0.1.sql и т.д.Эти файлы используются для обновления наших промежуточных и производственных баз данных.

Этот процесс работает у нас до сих пор, но внутри компании были некоторые дебаты о том, как наилучшим образом исправить схему.

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

Спасибо!

Answer 1

На работе для SQL Server мы пишем сценарии изменения схемы, которые сначала откатывают вносимое изменение (идемпотентно, поэтому раздел отката выполняется нормально, даже если изменение схемы еще не применено), а затем раздел для применения изменения.В TSQL легко заглянуть в системный каталог или другие таблицы, чтобы увидеть, существуют ли уже таблицы / столбцы / индексы / строки, и ничего не делать, если нет.

В PostgreSQL вы немного более ограничены в том, какие команды вы можете просто отправлять на сервер - но, с другой стороны, DDL является транзакционным, поэтому изменение схемы наполовину не должно происходить.Я довольно хорошо адаптировал схему, к которой привык на работе, для использования в своих собственных небольших проектах (перебор?но даже здесь у меня есть база данных разработчиков / тестов и "настоящая" база данных), например:

\echo Rolling back schema change #35

BEGIN;

DELETE FROM schema_version WHERE schema_id = 35;

DROP TABLE IF EXISTS location_coordinates;
DROP FUNCTION IF EXISTS location_coordinates_populate();

END;

\echo Applying schema change #35

BEGIN;

INSERT INTO schema_version(schema_id, description) VALUES(35, 'Add location_coordinates table');

CREATE TABLE location_coordinates(
 location_id INT PRIMARY KEY REFERENCES location(location_id),
 latitude FLOAT NOT NULL,
 longitude FLOAT NOT NULL,
 earth_coordinates earth NOT NULL,
 box_10miles cube NOT NULL
);

GRANT SELECT, INSERT, UPDATE, DELETE ON location_coordinates TO ui;

CREATE FUNCTION location_coordinates_populate() RETURNS TRIGGER LANGUAGE 'plpgsql' AS $$
BEGIN
  new.earth_coordinates := ll_to_earth(new.latitude, new.longitude);
  new.box_10miles := earth_box(new.earth_coordinates, 10 * 1609.344);
  RETURN new;
END
$$;

CREATE TRIGGER location_coordinates_populate BEFORE INSERT OR UPDATE ON location_coordinates
 FOR EACH ROW EXECUTE PROCEDURE location_coordinates_populate();

INSERT INTO location_coordinates(location_id, latitude, longitude)
 SELECT location_id, latitude, longitude FROM location WHERE latitude IS NOT NULL AND longitude IS NOT NULL;

CREATE INDEX location_coordinates_10miles ON location_coordinates USING gist (box_10miles);

END;

\echo Done

Этот скрипт может быть запущен в базе данных только с помощью "psql -f schema-changes/35.sql".Просто вырезав сообщение "применение ...", я могу получить команды для его отката.И, как вы можете видеть, изменение поддерживает таблицу метаданных "schema_version", так что я могу видеть, какие изменения применены.Все изменения выполняются в виде транзакции, переноса данных и всего остального.Здесь я использовал функцию "ЕСЛИ СУЩЕСТВУЕТ" команд УДАЛЕНИЯ, чтобы сделать раздел отката удовлетворительным, даже если изменение не применено.Istr одна вещь, которую мы делали на работе для Oracle, заключалась в записи изменений схемы как PL / SQL - возможно, у вас могли бы быть какие-то функции в plpgsql, которые помогли бы внести изменения?

Обратите внимание, что в приведенном выше изменении, где я переношу столбцы "широта" и "долгота" (которые можно было обнулить) из "location" в отдельное отношение "location_coordinates" (и добавляю данные earthdistance), я не удалял старые столбцы.Одна вещь, с которой мы должны быть осторожны, - это сделать изменения схемы обратно совместимыми, если это возможно.Таким образом, я могу применить это изменение схемы до того, как обновление приложения для использования новых таблиц.У меня было бы второе изменение, чтобы удалить старые столбцы для применения после обновление приложения.На работе это будет выполняться в двух разных циклах выпуска, поэтому во время выпуска X у нас все еще есть возможность отката приложения до выпуска X-1 без необходимости сначала откатывать все изменения схемы;а также возможность развертывать изменения схемы в отдельном окне перед запуском приложений.(Технически я должен был написать триггер, чтобы обновления старой таблицы синхронизировались с новой таблицей, но я этого не сделал, потому что это слишком похоже на работу :))

У нас также есть такие вещи, как приложение, которое просматривает все наши базы данных, чтобы увидеть, что находится в schema_version таблица и отслеживает изменения, так что люди могут даже увидеть, какие изменения были внесены без необходимости подключения, и получить представление об истории каждого изменения (мы отслеживаем "откат в dev", "применено в dev" и т.д.).На работе наша таблица schema_version также содержит информацию об авторстве и т.д.Волшебный способ применения информации о версии из системы управления версиями был бы крутым - одна из проблем, с которой мы сталкиваемся, заключается в том, что если SC применяется, например, в QA, а затем изменяется волей-неволей, возможно, никто не замечает.Таким образом, был бы хорош способ отследить, что было применено изменение схемы 35 редакции № 4.

Следует отметить одну вещь - изменения схемы для нас нумеруются независимо от версий приложения.Очевидно, что они связаны - это еще одна вещь, которую приложение-паук позволяет пользователям вводить --- но мы стараемся вносить множество небольших изменений, а не гигантский патч "вот все для выпуска X".Изменения схемы также используются для таких вещей, как добавление новых индексов, поэтому могут вообще не зависеть от приложения.Как правило, изменения схемы "принадлежат" разработчикам, а не администраторам баз данных - хотя в приведенном выше примере "создать индекс" администратор базы данных в основном выступает в роли разработчика и владеет изменением схемы.Да, мы настаиваем на высоком уровне владения SQL от разработчиков, хотя другие группы в компании работают немного по-другому и дают больше работы команде БД.