Parches de esquema Prácticas

Question

Tenemos un esquema en Postgres, y queremos instituir un buen método para aplicar los parches de esquema.

En la actualidad, tenemos una serie de archivos DDL que crean los esquemas, tablas, secuencias, funciones, etc. También tenemos una secuencia de comandos de la población para entornos de prueba. Estos archivos son utilizados para recrear los entornos de bases de datos, para el desarrollo, pruebas, etc.

También tenemos una serie de archivos de 'parche' que corresponden a versiones de nuestro sistema. es decir. parches / 1.0.0.sql, parches / 1.0.1.sql, etc. Estos archivos se utilizan para actualizar nuestras bases de datos de ensayo y producción.

Este proceso funciona para nosotros hasta ahora, pero no ha habido cierto debate internamente cómo parchar mejor el esquema.

Tengo curiosidad por lo demás por ahí tiene, como un proceso, parchear y puesta en escena del esquema de producción y la forma de gestionar las versiones de la base de datos.

Gracias!

Answer 1

En el trabajo, para SQL Server, se escribe guiones cambio de esquema que el primer rollo de nuevo el cambio a realizar (idempotently, por lo que la sección de reversión funciona muy bien incluso si el cambio de esquema no se aplica todavía), y luego una sección de aplicar el cambio. En TSQL es fácil mirar en el catálogo del sistema o de otras tablas para ver si las tablas / columnas / filas / índices ya existen y no hacen nada si no.

En PostgreSQL, eres un poco más restringida con los comandos que puede simplemente enviar a la server-- pero, por otro lado, DDL es transaccional, por lo que un cambio en el medio aplicado esquema no debería suceder. He adaptado el esquema que estoy acostumbrado en el trabajo a utilizar en mis propios pequeños proyectos bastante bien, por ejemplo (una exageración, pero incluso en este caso tengo una base de datos de desarrollo / pruebas y una base de datos "real"?):

\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

Este script se puede ejecutar en la base de datos solo con "psql -f esquema-cambios / 35.sql". Con sólo cortar hasta la "... la aplicación" mensaje, puedo conseguir los comandos para rodar de nuevo. Y como se puede ver, el cambio mantiene una tabla de metadatos "SCHEMA_VERSION" para que pueda ver la que se aplican los cambios. El cambio completo se lleva a cabo como una transacción, la migración de datos y todo. Aquí he utilizado el "SI EXISTE" capacidad de la GOTA comandos para hacer que la sección de reversión feliz, incluso cuando el cambio es no aplicado. Istr una cosa que hizo en el trabajo para Oracle fue los cambios de esquema de escritura como PL / SQL-- que tal vez podría tener algunas funciones en plpgsql para ayudar con hacer cambios?

Tenga en cuenta que en el cambio anterior, donde estoy migrando la "latitud" y "columnas" de longitud (que eran anulable) de "localización" a una relación separada "location_coordinates" (y la adición de la materia earthdistance), no deje caer las viejas columnas. Una cosa que tenemos que tener cuidado es hacer compatible con versiones anteriores cambios de esquema si es posible. Así que se puede aplicar este cambio de esquema antes actualizar la aplicación para utilizar las nuevas tablas. Tendría un segundo cambio de retirar los viejos columnas de aplicar después actualización de la aplicación. En el trabajo, éstas se llevaría a cabo en dos ciclos de lanzamiento diferentes, por lo que durante la liberación X todavía tenemos la opción de hacer retroceder la aplicación para liberar X-1 sin tener que retroceder en primer lugar todos los cambios de esquema; así como ser capaz de implementar los cambios de esquema en una ventana separada antes de las aplicaciones. (Técnicamente debería haber escrito un disparador para que las actualizaciones a la mesa de edad se sincronizan con la nueva tabla, pero no tienen porque eso es un trabajo demasiado:))

También tenemos cosas como una aplicación que las arañas de todas nuestras bases de datos para ver qué hay en la mesa schema_version y seguimiento de los cambios, por lo que la gente puede incluso ver qué cambios se hicieron sin tener que conectar y tener una idea de la historia de cada el cambio (rastreamos "deshace en dev", "aplicado en dev", etc). En el trabajo de nuestra mesa SCHEMA_VERSION también incluye información de autoría, etc. Una forma mágica de la aplicación de la información de la versión del control de versiones sería guay, un problema que tenemos es que si un SC se aplica en el control de calidad, por ejemplo, entonces cambió en Perforce, tal vez sin avisos -uno. Así que una manera de realizar un seguimiento de que el cambio de esquema de revisión 35 # 4 se aplicó sería bueno.

Una cosa a nota- cambios de esquema para nosotros se numeran de forma independiente de las versiones de la aplicación. Obviamente ellos están relacionados --- eso es otra cosa que la aplicación de rastreo permite a la gente a entrar --- pero tratamos de tener un montón de pequeños cambios en lugar de un gigante "aquí está todo lo necesario para la liberación X" parche. Los cambios de esquema también se utilizan para cosas como la adición de nuevos índices, por lo que podrían no ser impulsada aplicación en absoluto. En general, los cambios de esquema son "propiedad" de los desarrolladores, no DBAs- aunque en el "índice de crear" ejemplo anterior, el DBA es, básicamente, actuando en un papel de promotor y poseer el cambio de esquema. Sí, insistimos en un alto nivel de capacidad de SQL-desarrolladores- aunque otros grupos de la sociedad funcionan un poco diferente y le dan más trabajo que el equipo de DB.