Leandro Guimarães Faria Corcete DUTRA wrote: > Creio que cheguei a mencionar no assunto original que versionamento > seria trivial de fazer com texto, mas é difícil e caro com diagramas. > Por que é caro? Se você representar os dados em um formato semi-estruturado (XML por exemplo) fica fácil adicionar versionamento.
> Não é uma ferramenta, mas um processo com várias ferramentas. > > Escreve-se o modelo em D, onde claro é uma linguagem relacional sã e > completa. > Acho que o foco é montar uma estrutura que possa ser traduzida para vários SGBDs. Particularmente, acho que D não seria a melhor opção. Na minha opinião, uma estrutura semi-estruturada seria uma boa pois você pode definir um modelo próximo a estrutura dos bancos de dados suportados e escrever um tradutor (XSLT por exemplo) para transformar o modelo em DDL/DML necessários. Fácil, simples e rápido. > Daí aparecem várias possibilidades e (ou) necessidades. Reversas de > diversos sabores de SQL para D, relatório sobre partes do modelo que não > puderam ser implementadas em determinado sabor SQL (por exemplo, algumas > restrições de integridade), um AutoDoc para D, tradutores para diversos > sabores SQL e comandos DML (aí sim já saindo do âmbito de modelagem), e > vai por aí afora. > A parte reversa seria um pouco mais complicada. Teria que existir tradutores diferentes para cada SGBD suportado; esses tradutores fariam a leitura do catálogo ou dicionário de dados de cada SGBD e transformaria isso no modelo (XML?) suportado pela ferramenta. A documentação de tais diagramas poderia ser feita em qualquer uma das partes (diagrama gerado ou catálogo). Utilizando o diagrama, poderia ser criado um novo tradutor (XSLT por exemplo) para gerar um relatório (HTML?) específico para um SGBD ou um genérico. -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
