[firebase-br] Sincronização de alterações no banco pelos programadores

[Gladiston Santana]

Creio que isso pode variar de empresa para empresa.
Aqui é mais tranquilo funcionando da seguinte forma, há uma pasta chamada
_Database e dentro dela subpastas separadas por tipos de objetos, por
exemplo:
(...)/Source/_database/scripts/01-roles
(...)/Source/_database/scripts/02-exceptions
(...)/Source/_database/scripts/03-dominios
(...)/Source/_database/scripts/04-tabelas
(...)/Source/_database/scripts/05-tabelas_alter
(...)/Source/_database/scripts/06-tabelas_alter_fk
(...)/Source/_database/scripts/07-compute_by
(...)/Source/_database/scripts/20-views
(...)/Source/_database/scripts/60-sp_functions
(...)/Source/_database/scripts/61-sp
(...)/Source/_database/scripts/70-triggers
(...)/Source/_database/scripts/80-comentarios
(...)/Source/_database/scripts/90-basedata
(...)/Source/_database/scripts/91-constraints
(...)/Source/_database/scripts/92-indices
(...)/Source/_database/scripts/95-permissoes


' tabelas ' contem um arquivo para cada 'create table', outra pasta
'tabelas_alter' contendo um arquivo para cada tabela que criaria campos
adicionais(ou drops) que se fezem necessarios, idem para indices, compute
by, FK´s, etc...
mas esses script tem de ser  autosuficientes , isto é, eles tratam das
modificações necessárias partir da linha base original (desde a primeira
versão do banco de dados).
Por exemplo, na pasta  'tabelas_alter_fk'   eu tenho um arquivo chamado
ALMOX_UNID.SQL que cria todas as FKs para a tabela de mesmo nome. Ela tem
de ser acumulativa desde a linha base, então ela tá assim:
SET TERM ^ ;
EXECUTE BLOCK AS
DECLARE TABLE_NAME VARCHAR(255);
DECLARE TABLE_ALIAS VARCHAR(255);
DECLARE CONSTRAINT_NAME VARCHAR(255);
DECLARE FOREIGN_KEY VARCHAR(255);
DECLARE REFERENCES_SQL VARCHAR(255);
BEGIN
  TABLE_NAME='ALMOX_UNID';
  TABLE_ALIAS='ALMOX_UNID';
  -- FK #1
  FOREIGN_KEY='CODITEM_ALMOX';
  CONSTRAINT_NAME=LEFT('FK_'||TABLE_ALIAS||'_'||:FOREIGN_KEY,31);
  REFERENCES_SQL='ALMOX(CODITEM_ALMOX)';
  IF (NOT EXISTS(
        SELECT 1 FROM RDB$RELATION_CONSTRAINTS
        WHERE RDB$CONSTRAINT_NAME = :CONSTRAINT_NAME )) THEN
      EXECUTE STATEMENT
        'ALTER TABLE '||:TABLE_NAME||
        ' ADD CONSTRAINT '||:CONSTRAINT_NAME||
        ' FOREIGN KEY ('||:FOREIGN_KEY||')'||
        ' REFERENCES '||:REFERENCES_SQL||' '||
        'ON UPDATE CASCADE;';

  -- FK #2
  FOREIGN_KEY='UNIDADE_ORIGEM';
  CONSTRAINT_NAME=LEFT('FK_'||TABLE_ALIAS||'_'||:FOREIGN_KEY,31);
  REFERENCES_SQL='ADMIN_UNIDADES (UNIDADE)';
  IF (NOT EXISTS(
        SELECT 1 FROM RDB$RELATION_CONSTRAINTS
        WHERE RDB$CONSTRAINT_NAME = :CONSTRAINT_NAME )) THEN
      EXECUTE STATEMENT
        'ALTER TABLE '||:TABLE_NAME||
        ' ADD CONSTRAINT '||:CONSTRAINT_NAME||
        ' FOREIGN KEY ('||:FOREIGN_KEY||')'||
        ' REFERENCES '||:REFERENCES_SQL||' '||
        'ON UPDATE CASCADE;';

  -- FK #3
  FOREIGN_KEY='UNIDADE_DESTINO';
  CONSTRAINT_NAME=LEFT('FK_'||TABLE_ALIAS||'_'||:FOREIGN_KEY,31);
  REFERENCES_SQL='ADMIN_UNIDADES (UNIDADE)';
  IF (NOT EXISTS(
        SELECT 1 FROM RDB$RELATION_CONSTRAINTS
        WHERE RDB$CONSTRAINT_NAME = :CONSTRAINT_NAME )) THEN
      EXECUTE STATEMENT
        'ALTER TABLE '||:TABLE_NAME||
        ' ADD CONSTRAINT '||:CONSTRAINT_NAME||
        ' FOREIGN KEY ('||:FOREIGN_KEY||')'||
        ' REFERENCES '||:REFERENCES_SQL||' '||
        'ON DELETE CASCADE ON UPDATE CASCADE;';
END
^
SET TERM ;^

Como pode notar, ela é autosuficiente porque só cria FKs que não existam,
mas se fosse o caso de remover, eu usaria a mesma tecnica com DROP.
Eu tenho esqueletos do tipo acima para VIEWS, DOMAINS,... todos eles
conferindo existencia e usando alter ou drop. Além disso, um esqueleto para
cada estilo de objeto me permite ter algum padrão para nomes dos objetos
criados/dropados e assim evitando que programadores usem um jeito
'inventivo' de se fazer a mesma coisa com comandos ou nomes diferentes sem
as salvaguardas necessárias.
Além disso, os programadores estão proibidos de aplicar estes scripts
'standalone', eles tem de usar um programa especial que roda todos os
scripts dessa pasta principal (por isso, elas foram numeradas) e daí ter a
certeza de que algo feito por um programador não detonou a outra.
Essa estrutura só existe para o banco de dados e por enquanto, não tô
precisando de versioamento, apenas backups.


Em sex, 25 de jan de 2019 às 17:00, Rodrigo <rodrigo em digibyte.com.br>
escreveu:

>
> Boa tarde, hoje trabalhamos em 3 programadores e os 3 podem fazer
> alterações no banco. Eu centralizo tudo, comparo com cada um e com
> muuuuuito cuidado vou subindo as alterações pro BD padrão. Esse processo é
> muito custoso, demorado e sujeito a erros. Com certeza grandes empresas tem
> um processo totalmente diferente desse mas gostaria de saber como eu
> poderia trabalhar aqui de uma forma mais inteligente. Talvez trabalhar com
> os scripts no svn?
>
> Obrigado.
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>


-- 
A Vidy possui um Sistema de Gestão da Qualidade estruturado e com
Certificação ISO 9001 há mais de 10 anos, mantendo seu foco na Qualidade e
na Melhoria Continua.

Em março de2018 migramos com sucesso para a nova versão da ISO 9001.

Somos a única Empresa Brasileira de Engenharia de Laboratórios com
certificação com o Escopo Completo; desde Projetos, Engenharia, Construção,
Fabricação e Instalação de Laboratórios.