Schéma pratiques Patches

Question

Nous avons un schéma dans Postgres, et nous voulons mettre en place une bonne méthode pour appliquer les correctifs de schéma.

À l'heure actuelle, nous avons une série de fichiers qui créent les DDL schéma, tables, séquences, fonctions, etc. Nous avons aussi un script de la population pour les environnements de test. Ces fichiers sont tous utilisés pour recréer nos environnements de bases de données, pour le développement, les tests, etc.

Nous avons aussi un certain nombre de fichiers « patch » qui correspondent aux versions de notre système. c'est à dire. patches / 1.0.0.sql, patches / 1.0.1.sql, etc. Ces fichiers sont utilisés pour mettre à jour nos bases de données de mise en scène et de production.

Ce processus fonctionne pour nous jusqu'à présent, mais il y a eu un débat en interne comment patcher mieux le schéma.

Je suis curieux de ce que d'autres là-bas ont, en tant que processus, patcher mise en scène et le schéma de production et de la façon de gérer les versions de la base de données.

Merci!

Answer 1

Au travail, SQL Server, nous écrivons les scripts de changement de schéma que le premier rouleau arrière de la modification à apporter (idempotently, de sorte que la section de restauration fonctionne bien, même si le changement de schéma est pas encore appliqué), puis une section appliquer la modification. En TSQL il est facile de jeter un regard dans le catalogue du système ou d'autres tables pour voir si tables / colonnes / indices / lignes existent déjà et ne rien faire sinon.

Dans PostgreSQL, vous êtes un peu plus limité avec ce que les commandes que vous pouvez simplement envoyer au Server--, mais d'autre part, est transactionnel DDL, donc un changement de schéma moitié appliqué ne devrait pas se produire. Je l'ai adapté le système que je suis habitué au travail à utiliser sur mes propres petits projets très bien, par exemple (surpuissant mais même ici, j'ai dev / test db et db « vrai »?):

\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

Ce script peut être exécuté sur la base de données juste avec « psql -f schéma modifications / 35.sql ». En tout découper à la « application ... » message, je peux obtenir les commandes pour rouler en arrière. Et comme vous pouvez le voir, le changement maintient une table de métadonnées « schema_version » afin que je puisse voir quels changements sont appliqués. Le changement complet se fait comme une transaction, la migration des données et tous. Ici, je l'ai utilisé la capacité « IF EXISTS » de la commande DROP pour rendre la section rollback heureux, même lorsque le changement est inappliquée. Istr une chose que nous avons fait au travail pour Oracle était les changements de schéma écriture en tant que PL / SQL-- vous pourriez peut-être avoir des fonctions plpgsql pour aider à faire des changements?

Notez que dans le changement ci-dessus, où je migration la relation « latitude » et colonnes « de longitude » (qui étaient annulable) sur « l'emplacement » à un « location_coordinates » séparée (et en ajoutant la substance earthdistance), Je ne laissez pas tomber les vieilles colonnes. Une chose que nous devons faire attention est de faire des changements de schéma rétrocompatible si possible. Je peux donc appliquer ce changement de schéma avant mettre à jour l'application pour utiliser les nouvelles tables. J'ai un deuxième changement d'abandonner les anciennes colonnes à appliquer après mise à jour de l'application. Au travail, ceux-ci seraient en fait deux cycles de libération différents, de sorte que lors de la libération X, nous avons encore l'option de faire reculer l'application pour libérer X-1 sans avoir à faire reculer toutes les modifications du schéma premier; tout en étant en mesure de déployer des modifications de schéma dans une fenêtre séparée avant que les applications. (Techniquement, je aurait dû écrire un déclencheur si des mises à jour à l'ancienne table sont synchronisées à la nouvelle table, mais je n'ai pas parce que c'est trop comme travail:))

Nous avons aussi des choses comme une application qui araignées toutes nos bases de données pour voir ce qui est dans la table schema_version et le suivi des changements, afin que les gens peuvent même voir quels changements ont été faits sans avoir à se connecter, et avoir une idée de l'histoire de chaque changement (nous surveillons « roulée en dev », « appliqué dans dev », etc.). Au travail de notre table schema_version comprend également des informations d'auteur, etc. Une façon magique d'appliquer les informations de version du contrôle de version serait COOL- un problème que nous avons est que si un SC soit appliquée dans QA, par exemple, puis a changé en Perforce, peut-être pas avis -one. Ainsi, un moyen de suivre ce changement de schéma 35 révision n ° 4 a été appliqué serait bon.

Une chose à NOTE- changements de schéma pour nous sont dénombrées indépendamment des versions d'application. De toute évidence, ils sont liés --- c'est une autre chose que l'application spidering permet aux gens d'entrer --- mais nous essayons d'avoir beaucoup de petits changements plutôt qu'un géant « tout est ici pour version X » patch. Les modifications de schéma sont également utilisés pour des choses comme l'ajout de nouveaux indices, donc pourraient ne pas être conduit app-tout. En général, les changements de schéma sont « propriété » par les développeurs, pas DBAs- bien que dans l'exemple « créer un index » ci-dessus, le DBA est essentiellement agit dans un rôle de développeur et propriétaire du changement de schéma. Oui, nous insistons sur un haut niveau de SQL capacité de developers- bien que d'autres groupes de la société travaillent un peu différemment et donner plus de travail à l'équipe DB.