Em Qua, 2007-07-18 às 15:45 -0300, Euler Taveira de Oliveira escreveu:
> 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?
Era referência a quanto se cobra nas ferramentas proprietárias…
> Se você representar os dados em um formato
> semi-estruturado
O que você quer dizer com isso?
> (XML por exemplo) fica fácil adicionar versionamento.
Exatamente — as ferramentas tradicionais não têm tal formato, só para
exportação.
E os diagramas aí só complicam, como o XML também. Um D basta, e é
mais simples e direto.
> > 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.
Por quê?
Eu quero um D, porque quero algo que não se restrinja às capacidades
dos atuais SGBD. Quero algo que dê conta de qualquer extensão ao SQL, e
a eventuais SGBDRs, assim como outras cositas menos cotadas como
quase-SGBDs.
> 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.
Cara, pára de colocar XML no meio… não tem necessidade. Se não for um
D, vai ISO SQL mesmo. Para que algo mais complicado que isso?
> 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.
Claro. Mas não creio que seja tão difícil, afinal os catálogos
costumam não ser tão ruins… exceto o do MS SQL Server que é chato e o do
MySQL que é péssimo, mas sempre se pode trabalhar de DDLs exportados ou
do INFORMATION_SCHEMA que começa a ser amplamente suportado (MySQL v5,
por exemplo).
O negócio é começar com um decente (PostgreSQL), aí fazer um outro
quase tanto quanto (DB2), depois os razoáveis (Oracle), e depois o resto
(vide acima).
> A documentação de tais diagramas poderia ser feita em qualquer uma das
> partes (diagrama gerado ou catálogo).
Que diagrama? Lembre-se, a idéia é simplesmente gerar diagramas com um
AutoDoc da vida.
> 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.
Não, esqueça o diagrama! O D da vida é o cerne da coisa.
Mas você lembrou bem, outra ferramenta seria um gerador de relatórios.
E tanto faz, RTF, SGML [(X)HTML ou coisa que o valha], ODF, LaΤeχ…
--
Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas SP, BR
msnim:[EMAIL PROTECTED]
skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151
- - - - -
Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta
mensagem por engano, por favor avise imediatamente o remetente, respondendo o
e-mail e em seguida apague-o. Agradecemos sua cooperacao.
Privacy Policy: This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
