Esquema Patches Práticas

Question

Nós temos um esquema no Postgres, e queremos instituir um bom método para aplicar patches de esquema.

Atualmente, temos uma série de arquivos DDL que criar o esquema, tabelas, seqüências, funções, etc. Temos também um roteiro população para ambientes de teste. Esses arquivos são usados ??para recriar os nossos ambientes de banco de dados, para o desenvolvimento, testes, etc.

Temos também um número de arquivos 'remendo' que correspondem às versões do nosso sistema. ie. manchas / 1.0.0.sql, manchas / 1.0.1.sql, etc. Esses arquivos são usados ??para atualizar nossas bases de dados de teste e produção.

Este processo funciona para nós até agora, mas tem havido algum debate in-house como melhor remendo do esquema.

Estou curioso o que os outros lá fora, têm, como um processo, ao estadiamento patch e produção esquema do e como gerenciar versões do banco de dados.

Obrigado!

Answer 1

No trabalho, para o SQL Server, podemos escrever scripts de alteração de esquema que primeiro rolo de volta a mudança a ser feita (idempotently, então a seção de reversão funciona muito bem mesmo se a mudança de esquema não é ainda aplicada), e, em seguida, uma seção para aplicar a alteração. Em TSQL é fácil espiada no catálogo do sistema ou outras tabelas para ver se tabelas / colunas / índices / linhas já existem e não fazer nada se não.

Em PostgreSQL, você é um pouco mais constrangido com o que ordena que você pode simplesmente enviar para o server-- mas, por outro lado, DDL é transacional, por isso uma alteração de esquema meia aplicada não deve acontecer. Eu adaptei o esquema eu estou acostumado a no trabalho para uso em meus próprios projetos pequenos muito bem (um exagero, mas mesmo aqui eu tenho um db dev / teste e um db "real"?), Por exemplo:

\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 pode ser executado no banco de dados apenas com "psql -f esquema-changes / 35.sql". Por apenas cortar-se à "aplicação ..." mensagem, posso obter os comandos para revertê-lo. E como você pode ver, a mudança mantém uma tabela de metadados "schema_version" para que eu possa ver quais alterações são aplicadas. Toda a mudança é feita como uma operação, migração de dados e tudo. Aqui eu usei o "SE EXISTE" capacidade dos comandos DROP para fazer a feliz secção de reversão, mesmo quando a mudança é aplicada. Istr uma coisa que fizemos no trabalho para Oracle foi alterações de esquema de escrita como PL / SQL-- você poderia talvez ter algumas funções em plpgsql para ajudar a fazer alterações?

Note que na mudança de cima, onde eu estou migrando a "latitude" e colunas "longitude" (que foram anulável) fora do "local" para um "location_coordinates" relação separado (e adicionando o material earthdistance), Eu não deixar cair as colunas antigas. Uma coisa que temos de ter cuidado é para fazer alterações de esquema compatível com versões anteriores, se possível. Então eu posso aplicar esta alteração de esquema antes atualizar o aplicativo para usar as novas tabelas. Eu teria uma segunda mudança para largar as velhas colunas de aplicar após atualizar o aplicativo. No trabalho, estes seria feito em dois ciclos de lançamento diferentes, por isso durante a liberação X ainda temos o opcional de reverter o aplicativo para liberar X-1 sem ter que rolar para trás todo o esquema muda em primeiro lugar; bem como ser capaz de implantar mudanças de esquema em uma janela separada antes dos aplicativos. (Tecnicamente eu deveria ter escrito um gatilho para que as atualizações para a tabela antiga são sincronizados com a nova tabela, mas eu não tenho porque isso é muito como trabalho:))

Temos também coisas como um aplicativo que aranhas todas as nossas bases de dados para ver o que está na tabela de schema_version, e controla as alterações, para que as pessoas podem até mesmo ver quais alterações foram feitas sem ter que se conectar, e ter uma idéia da história de cada mudança (rastreamos "back rolou em dev", "aplicada em dev" etc). No trabalho nossa mesa schema_version também inclui informações autoria etc. Uma maneira mágica de aplicar as informações de versão do controle de versão seria problema se refrescar-que temos é que se um SC é aplicado em QA, por exemplo, em seguida, mudou em Perforce, talvez não avisos -um. Assim, uma maneira de controlar que a mudança do esquema 35 revisão # 4 foi aplicada seria bom.

Uma coisa a esquema nota- muda para nós são numeradas independentemente das versões de aplicativos. Obviamente eles estão relacionados --- isso é outra coisa que o aplicativo spidering permite que as pessoas para entrar --- mas nós tentamos ter muitas pequenas mudanças, em vez de um gigante "tudo está aqui para liberação X" patch. As alterações de esquema também são usados ??para coisas como a adição de novos índices, por isso pode não ser de todo-driven aplicação. Em geral, as alterações de esquema são "propriedade" de desenvolvedores, não DBAs- embora no exemplo "criar o índice" acima, o DBA é basicamente atuando em um papel de desenvolvedor e possuir a mudança de esquema. Sim, insistimos em um alto nível de SQL-capacidade de desenvolvedores- embora outros grupos no trabalho da empresa um pouco diferente e dar mais trabalho para a equipe de DB.