Re: [pgbr-geral] Modelagem de Dados à la Unix
Lindolfo, em primeiro lugar bem-vindo. Em segundo lugar, antes de responder, procure seguir a netiqueta, RFC 1855… especificamente, não escreva reaproveitando mensagens anteriores, porque isso bagunça a linha de de assunto (Re: no começo), engorda a mensagem (texto original no final) e confunde os agrupamentos de mensagens realizados pelos agentes de usuário (clientes) de correio eletrônico. Aliás, agora vi que você respondeu uma mensagem relevante, na verdade… me confundi, por ser uma mensagem antiga. Nesses casos é bom explicar o que você fez, como 'Retomando um assunto antigo'; e tem de citar somente o texto relevante à resposta, respondendo após os trechos citados. Agora, vamos ao que interessa. 2007/12/8, Lorn <[EMAIL PROTECTED]>: > Oi pessoal, eu conheci a ideia no pgcon 2007 e gostaria de saber se alguem > fez algum tipo de rascunho dessa "linguagem" para especificar o SQL ? Bom, sim. Mas há alguns detalhes. Primeiro, há várias possibilidades de linguagem. Em dois campos: o completa e indubitavelmente relacional, que vamos chamar de D ― explicações a seguir. E o polêmico, que seria o ISO SQL:2003 ― que não é relacional, e há controvérsias sérias sobre se presta. D na verdade é o nome que se dá a uma classe de linguagens onde qualquer D é relacional ― não confundir com a linguagem de programação de sistemas D, que é um sucessor do C. Exemplos de D como classe de linguagens relacionais seriam o Tutorial D, uma linguagem criada para fins didáticos pelo Date e o Darwen no estilo do COBOL, e o D4, especialmente na primeira versão. Existem alguns Ds listados em http://www.thethirdmanifesto.com/ e http://dmoz.org/Computers/Software/Databases/Relational/Implementations/, vale a pena estudar o assunto. Existe inclusive uma gramática BNF do Tutorial D listada no The Third Manifesto (o sítio). -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Oi pessoal, eu conheci a ideia no pgcon 2007 e gostaria de saber se alguem fez algum tipo de rascunho dessa "linguagem" para especificar o SQL ? ou até um rascunho em D especificando isso.Pelo que eu entendi o pessoal chegou a conclusão que XML não é legal pra isso, eu concordo. On Jul 19, 2007 3:29 PM, Roberto Mello <[EMAIL PROTECTED]> wrote: > On Wed, Jul 18, 2007 at 06:25:27PM -0300, Euler Taveira de Oliveira wrote: > > > > > Não entendi porque XML complica. Não sei se um parser para D é melhor do > > que um parser XML, mas é mais fácil encontrar um parser XML do que um em > D. > > Por que XML, por definicao, e' complicado. Como disse o James Clark > (inventor do XML): "any damn fool could produce a better data format than > XML." > > > E quem disse que com um esquema XML você vai restringir capacidades? Se > > a sua estrutura for bem montada, você pode armazenar quaisquer tipos de > > "objetos" e propriedades que o seu SGBD suportar. > > A meu ver, parece uma reinvencao da roda, desnecessaria. > > > Por que por XML no meio? Simplesmente porque uma representação em D ou > > SQL é difícil de fazer um "parsing"; O XML tem uma estrutura bem > > definida, assim podemos obter a informação precisa (com XPath ou > XQuery). > > XML nao tem estrutura definida, nao a estrutura que vai ser util para a > aplicacao em questao. Voce mesmo disse acima que "SE a sua > estrutura [em XML] for bem montada" (enfase minha). SE for bem montada. > Quer dizer que ainda tem que design e montar a estrutura. > > -Roberto > > -- > "In the long run, every program becomes rococo, and then rubble." >-- Alan Perlis > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Lindolfo "Lorn" Rodrigues - www.slackwarezine.com.br - http://lornlab.org - http://sao-paulo.pm.org use Catalyst; ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
On Wed, Jul 18, 2007 at 06:25:27PM -0300, Euler Taveira de Oliveira wrote: > > > Não entendi porque XML complica. Não sei se um parser para D é melhor do > que um parser XML, mas é mais fácil encontrar um parser XML do que um em D. Por que XML, por definicao, e' complicado. Como disse o James Clark (inventor do XML): "any damn fool could produce a better data format than XML." > E quem disse que com um esquema XML você vai restringir capacidades? Se > a sua estrutura for bem montada, você pode armazenar quaisquer tipos de > "objetos" e propriedades que o seu SGBD suportar. A meu ver, parece uma reinvencao da roda, desnecessaria. > Por que por XML no meio? Simplesmente porque uma representação em D ou > SQL é difícil de fazer um "parsing"; O XML tem uma estrutura bem > definida, assim podemos obter a informação precisa (com XPath ou XQuery). XML nao tem estrutura definida, nao a estrutura que vai ser util para a aplicacao em questao. Voce mesmo disse acima que "SE a sua estrutura [em XML] for bem montada" (enfase minha). SE for bem montada. Quer dizer que ainda tem que design e montar a estrutura. -Roberto -- "In the long run, every program becomes rococo, and then rubble." -- Alan Perlis ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Qua, 2007-07-18 às 18:25 -0300, Euler Taveira de Oliveira escreveu: > Não entendi porque XML complica. Não sei se um parser para D é melhor do > que um parser XML, mas é mais fácil encontrar um parser XML do que um em D. Mas eu não quero escrever XML, nem diagramar. Quero escrever D e ter o diagrama automaticamente gerado. > E quem disse que com um esquema XML você vai restringir capacidades? Se > a sua estrutura for bem montada, você pode armazenar quaisquer tipos de > "objetos" e propriedades que o seu SGBD suportar. Não é essa a idéia, a idéia é escrever o modelo conceitual, com todas as regras de negócios. Vai ter de criar um esquema XML muito mais complicado que uma D. > Por que por XML no meio? Simplesmente porque uma representação em D ou > SQL é difícil de fazer um "parsing"; O XML tem uma estrutura bem > definida, assim podemos obter a informação precisa (com XPath ou XQuery). D também tem uma estrutura bem definida. Por isso é uma linguagem de programação, não uma linguagem natural. E é muito mais fácil de ler, escrever e depurar. Por exemplo, essa minha idéia é um primeiro passo. Nada impede que depois se desenvolva num SGBDR virtual, como o Alphora Dataphor, ou mesmo num SGBDR completo. Você não vai querer XML como linguagem de programação e interação num SGBD. > > Que diagrama? Lembre-se, a idéia é simplesmente gerar diagramas com um > > AutoDoc da vida. > > > Você quer uma ferramenta que gere os diagramas a partir do catálogo do > BD ou uma ferramenta que, além disso, possa diagramar? Nem uma, nem outra. Vide proposta inicial, mas a idéia é escrever o modelo conceitual, e dele tanto traduzir automaticamente para diversos SGBDs quanto gerar diagramas à la AutoDoc. Capito? > Na última opção > um formato intermediário, seria ideal para o versionamento e > representação unificada do modelo de dados. Nem assim. D seria ideal para a representação do modelo de dados. -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Euler Taveira de Oliveira escreveu: > ... > >Por que por XML no meio? Simplesmente porque uma representação em D ou >SQL é difícil de fazer um "parsing"; O XML tem uma estrutura bem >definida, assim podemos obter a informação precisa (com XPath ou XQuery). > > Na sua visão, como seria para escrever o XML? Ou seja a como fazer a modelagem mesmo, pois o que *eu* quero é fazer isso usando qualquer editor de textos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Leandro Guimarães Faria Corcete DUTRA wrote: > E os diagramas aí só complicam, como o XML também. Um D basta, e é > mais simples e direto. > Não entendi porque XML complica. Não sei se um parser para D é melhor do que um parser XML, mas é mais fácil encontrar um parser XML do que um em D. > 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. > E quem disse que com um esquema XML você vai restringir capacidades? Se a sua estrutura for bem montada, você pode armazenar quaisquer tipos de "objetos" e propriedades que o seu SGBD suportar. > 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? > Por que por XML no meio? Simplesmente porque uma representação em D ou SQL é difícil de fazer um "parsing"; O XML tem uma estrutura bem definida, assim podemos obter a informação precisa (com XPath ou XQuery). >> 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. > Você quer uma ferramenta que gere os diagramas a partir do catálogo do BD ou uma ferramenta que, além disso, possa diagramar? Na última opção um formato intermediário, seria ideal para o versionamento e representação unificada do modelo de dados. -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
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
Re: [pgbr-geral] Modelagem de Dados à la Unix
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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Qua, 2007-07-18 às 14:46 -0300, Daniel Gaspary escreveu: > Que tal uma "revisão" do que buscam ? Sem problemas. > Estou meio confuso sobre o que vocês procuram e o que falta para > isso. Confesso que reli o primeiro mail da Thread e não entendi qual a > real necessidade. Talvez por não fazer parte do meu dia-a-dia a > necessidade de trabalhar com tanta modelagem como parece ser do seu > cotidiano. Realmente, apesar d’eu já ter pensado nisso antes, foi só me concentrando em modelagem que senti a importância e a oportunidade. >Talvez seja só lentidão minha que impede de entender... :). Me > interessei no assunto, mas acho que começaram a aparecer outras > necessidades nas ferramentas que saíam do assunto original. > Versionamento, por exemplo. Creio que cheguei a mencionar no assunto original que versionamento seria trivial de fazer com texto, mas é difícil e caro com diagramas. >De repente, alguém (o Leandro pode ser o mais indicado) poderia > listar de forma concisa as características dessa "ferramenta ideal" ou > "ambiente ideal" para modelar/analisar/manter um Banco de dados. 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. Traduz-se esse modelo em D para o(s) SQL(s) necessários. Essa é a essência. 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. Ficou mais claro? Uma outra maneira de pensar nisso seria reconstruir um Alphora Dataphor, ou um SGBDR baseado em SQL (que em si não é relacional), um tijolo de cada vez. -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Pessoal, Que tal uma "revisão" do que buscam ? Estou meio confuso sobre o que vocês procuram e o que falta para isso. Confesso que reli o primeiro mail da Thread e não entendi qual a real necessidade. Talvez por não fazer parte do meu dia-a-dia a necessidade de trabalhar com tanta modelagem como parece ser do seu cotidiano. Talvez seja só lentidão minha que impede de entender... :). Me interessei no assunto, mas acho que começaram a aparecer outras necessidades nas ferramentas que saíam do assunto original. Versionamento, por exemplo. De repente, alguém (o Leandro pode ser o mais indicado) poderia listar de forma concisa as características dessa "ferramenta ideal" ou "ambiente ideal" para modelar/analisar/manter um Banco de dados. Obrigado, Daniel On 7/18/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> wrote: > Em Qua, 2007-07-18 às 11:10 +, Johnny Taylor Faria Chaves escreveu: > > Eu pensei em escrever em algum D e transformar em XMI, para ter apenas um > > parser/tradutor ou seja o que for que fosse criado, mas parece que o XMI não > > serve nem para isso :( . > > ... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Qua, 2007-07-18 às 11:10 +, Johnny Taylor Faria Chaves escreveu: > Eu pensei em escrever em algum D e transformar em XMI, para ter apenas um > parser/tradutor ou seja o que for que fosse criado, mas parece que o XMI não > serve nem para isso :( . Em compensação o SQL Fairy poderia ser ao menos uma fonte de idéias… ou o Dataphor. > > 2) Alguns programas (vide http://thethirdmanifesto.com) que já processam > > Tutorial D, e o SQL Fairy para lidar com ISO SQL. > > Sabe de alguma tradução do manifesto? Não… > > Portanto, o que eu me preocuparia agora é com a seleção da linguagem… > > Certo, vou olhar SchemeQL e o thethirdmanifesto.com. Legal. -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Qua 18 Jul 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: > > 1) XMI não parece ser um D válido, portanto exigiria extensões > significativas. > > 2) XMI é uma linguagem de marcação de texto, não de programação. > > 3) XMI em si parece ser bastante complexo. Eu pensei em escrever em algum D e transformar em XMI, para ter apenas um parser/tradutor ou seja o que for que fosse criado, mas parece que o XMI não serve nem para isso :( . > > > Em contrapartida, já temos: > > 1) Pelo menos dois Ds válidos já definidos, Tutorial D e D4, além da > possibilidade de usar ISO SQL. > > 2) Alguns programas (vide http://thethirdmanifesto.com) que já processam > Tutorial D, e o SQL Fairy para lidar com ISO SQL. Sabe de alguma tradução do manifesto? > > Portanto, o que eu me preocuparia agora é com a seleção da linguagem… Certo, vou olhar SchemeQL e o thethirdmanifesto.com. -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Ter, 2007-07-17 às 17:44 +, Johnny Taylor Faria Chaves escreveu: > > Olhando as entradas da Wikipædia para XMI, MOF e correlatos parece que > > a gente introduziria mais complicações que soluções — o que o XMI daria > > de ganho em relação a ler um D qualquer e traduzir para os SQLs da vida? > > Apenas aproveitar as ferrramentas que já existam e que usem o XMI. Isso coloca alguns problemas: 1) XMI não parece ser um D válido, portanto exigiria extensões significativas. 2) XMI é uma linguagem de marcação de texto, não de programação. 3) XMI em si parece ser bastante complexo. Em contrapartida, já temos: 1) Pelo menos dois Ds válidos já definidos, Tutorial D e D4, além da possibilidade de usar ISO SQL. 2) Alguns programas (vide http://thethirdmanifesto.com) que já processam Tutorial D, e o SQL Fairy para lidar com ISO SQL. 3) Um exemplo arquitetural interessante, se fechado, que é o Alphora Dataphor; e um aberto, o SchemeQL. Isso o que me vem à mente, certamente há outros. Portanto, o que eu me preocuparia agora é com a seleção da linguagem… -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Ter 17 Jul 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: > Em Ter, 2007-07-17 às 16:40 +, Johnny Taylor Faria Chaves escreveu: > > > Gerar diagramas é tranqüilo, as ferramentas já existem e > > > bastaria adaptar. > > > > Estive pensando em gerar (seja de qual linguagem for que se utilizasse) > > para XMI, mas parece que não dá suporte a domínios, ou será que usa outro > > nome? > > > > As especificações do XMI: > > http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf > > Parece que tem algo em 4.14, mas sendo da OMG dá medo… > > Olhando as entradas da Wikipædia para XMI, MOF e correlatos parece que > a gente introduziria mais complicações que soluções — o que o XMI daria > de ganho em relação a ler um D qualquer e traduzir para os SQLs da vida? Apenas aproveitar as ferrramentas que já existam e que usem o XMI. -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Ter, 2007-07-17 às 16:40 +, Johnny Taylor Faria Chaves escreveu: > > Gerar diagramas é tranqüilo, as ferramentas já existem e bastaria > > adaptar. > > Estive pensando em gerar (seja de qual linguagem for que se utilizasse) para > XMI, mas parece que não dá suporte a domínios, ou será que usa outro nome? > > As especificações do XMI: > http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf Parece que tem algo em 4.14, mas sendo da OMG dá medo… Olhando as entradas da Wikipædia para XMI, MOF e correlatos parece que a gente introduziria mais complicações que soluções — o que o XMI daria de ganho em relação a ler um D qualquer e traduzir para os SQLs da vida? > > Versionar seria basicamente usar os RCS, CVS, Darcs da vida, o que > > for. Qualquer ferramenta de controle de código-fonte. > > Esse é um "efeito colateral" que ajuda também, como são feitos os controles > de > versão nos diagramas gráficos? Na mão, escritos em alguma parte no corpo do > próprio diagrama? Geralmente existe um repositório SQL que contém as versões, mas são ainda mais caros. -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Sex 06 Jul 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: ... > Gerar diagramas é tranqüilo, as ferramentas já existem e bastaria > adaptar. Estive pensando em gerar (seja de qual linguagem for que se utilizasse) para XMI, mas parece que não dá suporte a domínios, ou será que usa outro nome? As especificações do XMI: http://www.omg.org/cgi-bin/apps/doc?formal/05-09-01.pdf > > Versionar seria basicamente usar os RCS, CVS, Darcs da vida, o que > for. Qualquer ferramenta de controle de código-fonte. Esse é um "efeito colateral" que ajuda também, como são feitos os controles de versão nos diagramas gráficos? Na mão, escritos em alguma parte no corpo do próprio diagrama? -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
"Wallace Reis" <[EMAIL PROTECTED]> writes: > On 7/6/07, Leandro Guimarães Faria Corcete DUTRA > <[EMAIL PROTECTED]> wrote: >> Não vejo porque jogar XML no meio… > > Quando você disse: "ou ML para obter mais concisão e poder > programático"; pensei estar se referindo a Markup Language. Nossa, eu me acho ignorante em programação — mas não a ponto de atribuir essas qualidades a uma simples linguagem de marcação. ML no caso, como o Scheme que fazia parte da frase, é exemplo de linguagem de programação funcional. -- +55 (11) 9406 7191 http://br.geocities.com./lgcdutra/ +55 (11) 5685 2219 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 3040 7300 r151 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 5686 9607ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
On 7/6/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> wrote: > Não vejo porque jogar XML no meio… Quando você disse: "ou ML para obter mais concisão e poder programático"; pensei estar se referindo a Markup Language. -- wallace reis/wreis Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas/LABBI ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Johnny Taylor Faria Chaves <[EMAIL PROTECTED]> writes: >> Ter um conjunto de ferramentas bem modulares para modelar, gerar >> diagramas, alterar o modelo físico e fazer o versionamento do banco, >> seria ótimo. > > Talvez seja o caminho mais viável, alguma idéia? Essa exatamente foi minha idéia original. Ainda tenho algumas dúvidas; por exemplo, na minha idéia original o AD escreveria o modelo conceitual e gerar-se-ia o físico também textualmente, o qual o DBA poderia alterar; mas seria legal se já soubéssemos como o fluxo funcionaria por exemplo no caso de alterações no conceitual depois do físico ajustado; usar ferramentas de diferença e remendo (/diff/ e /patch/)? Gerar diagramas é tranqüilo, as ferramentas já existem e bastaria adaptar. Versionar seria basicamente usar os RCS, CVS, Darcs da vida, o que for. Qualquer ferramenta de controle de código-fonte. Mas de qualquer maneira, não sei bem por onde começar. -- +55 (11) 9406 7191 http://br.geocities.com./lgcdutra/ +55 (11) 5685 2219 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 3040 7300 r151 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 5686 9607ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
"Wallace Reis" <[EMAIL PROTECTED]> writes: > On 6/28/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> wrote: >> No caso, a gente começaria com uma gramática (por exemplo) Tutorial >> D ou D4. Talvez usar um derivado de Scheme ou ML para obter mais concisão >> e poder programático, creio que já fizeram um SchemeQL ou coisa assim. > > Leandro, não sei se vc conhece o projeto XCDSQL (XML (en)Coded and > Documented SQL)[1]. Talvez seria um bom começo. Olha, não tenho muita simpatia por forçar SGML fora de seu âmbito original, que é a documentação. Acho muito chique HTML 5 ou XHTML 2 com CSS, totalmente a favor de DocBook (embora esteja apaixonado por Τεχ) — mas não entendo o que pode ajudar em bases de dados. Eu pensei em Scheme, se alguém achar Tutorial D, D4 ou mesmo ISO SQL:2003 feios (e num certo nível, eu concordaria). Não vejo porque jogar XML no meio… Mas obrigado pela dica mesmo assim. -- +55 (11) 9406 7191 http://br.geocities.com./lgcdutra/ +55 (11) 5685 2219 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 3040 7300 r151 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 5686 9607ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
"Diogo Biazus" <[EMAIL PROTECTED]> writes: > Todos estamos, já pensei várias vezes em começar uma ferramenta de > modelagem, mas ponho fé no trabalho do Euler com o PgAdmin. Creio que isso não me é problema algum, porque me parece que o objetivo dele — aliás, do pgAdmin — é bem diferente do meu. Pelo que entendi, o pgAdmin inclui uma funcionalidade de modelagem básica e tradicional (gráfica) exclusivamente para o PostgreSQL. Eu quero modelagem completa — idealmente, todas as regras de negócio — *e textual* para qualquer SGBD. O único privilégio do PostgreSQL seria suportar um subconjunto maior da funcionalidade que a maioria dos outros SGBDs. > Também gosto da idéia. Embora trabalhar com diagramas seja interessante, > nenhuma ferramenta implementa eles de forma que sejam suficientes para o > processo de modelagem. E alguém tem alguma idéia de que forma os diagramas poderiam ser implementados com vistas à suficiência para modelagem? Particularmente, duvido que seja possível que sejam suficientes, muito menos eficientes. > O maior problema seriam as diferenças no tratamento de linhas > duplicadas, nulos, e outras diferenças fundamentais. Era o que eu temia. > Pois essas partes implicam mudanças no executor, índices e um monte de > coisas dentro do banco. Quisera eu entender essa parte interna. > A parte de sintaxe me parece mais tranquila, se você estiver disposto a > ter um híbrido relacional/sql como produto final não seria tão complicado. Bom, o SQL já é um híbrido relacional, então não vejo a graça… nesse caso seria melhor implementar o ISO SQL:2003 mesmo, ou algo derivado dele. >> Na verdade o Postgres original suportava QUEL, uma outra linguagem. >> E o 'primo' Ingres ainda suporta QUEL. Então imagino que seja viável, >> seja criando mais uma interface para o PostgreSQL, seja bifurcando o >> projeto. > > Sim, viável é, mas vale o esforço? Duvido. > Alterar o PostgreSQL para ter uma linguagem relacional me parece muito > esforço para pouco resultado (desculpem-me os idealistas). Acho que o resultado seria fantástico. Mas o esforço também. E tenho minhas dúvidas se seria uma adaptação ou uma bifurcação mesmo. > Acho a idéia do Leandro de ter um sistema de modelagem sobre o SGBD mais > interessante. Veja que não são idéias mutuamente excludentes. Na verdade acho que a minha poderia teoricamente facilitar a solução definitiva, que seria mesmo um SGBDR. Porque todos os modelos criados com a ferramente de modelagem poriam ser facilmente implementados num SGBDR; principalmente se compartilharem uma linguagem D, como talvez a Tutorial D, D4 ou, sei lá, um eventual SchemeD. > Mas quem sabe usamos UML? Então… fiquei espantadíssimo do UML não suportar nem domínios, pelo menos não obviamente. -- +55 (11) 9406 7191 http://br.geocities.com./lgcdutra/ +55 (11) 5685 2219 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 3040 7300 r151 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 5686 9607ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Qui 05 Jul 2007, Diogo Biazus escreveu: > O maior problema seriam as diferenças no tratamento de linhas > duplicadas, nulos, e outras diferenças fundamentais. > Pois essas partes implicam mudanças no executor, índices e um monte de > coisas dentro do banco. > A parte de sintaxe me parece mais tranquila, se você estiver disposto a > ter um híbrido relacional/sql como produto final não seria tão complicado. Poderia ser um híbrido, e (*eu*) só usar o relacional, mas, como já disse não tenho estrutura para algo assim. > Alterar o PostgreSQL para ter uma linguagem relacional me parece muito > esforço para pouco resultado (desculpem-me os idealistas). > Acho a idéia do Leandro de ter um sistema de modelagem sobre o SGBD mais > interessante. > Ter um conjunto de ferramentas bem modulares para modelar, gerar > diagramas, alterar o modelo físico e fazer o versionamento do banco, > seria ótimo. Talvez seja o caminho mais viável, alguma idéia? > > Mas quem sabe usamos UML? > (brincadeirinha) Arrumei um livro (UML Essencial), ainda estou no começo mas a impressão que estou tendo, e creio que já foi dito aqui (na postgresql-br), é que UML é boa para a análise e documentação *do sistema*, mas muitos querem leva-la para os bancos de dados. -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Enviei esta mensagem, para a lista e para o Leandro, mas a lista retornou com erro, provavelmente pelo problema já relatado pelo Fábio. -- Mensagem reenviada -- Subject: Re: [pgbr-geral] Modelagem de Dados à la Unix Date: Seg 02 Jul 2007 From: Johnny Taylor Faria Chaves <[EMAIL PROTECTED]> To: Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> Em Sex 29 Jun 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: > >>Esta é uma idéia bem incipiente, gostaria de discuti-la aqui. > >> Alguns podem achar que é fora do tópico; nesse caso, aceito > > sugestões > > >> de onde debatê-la. > > > > O ideal, seria na bancosdedados, mas, como voce disse em outra > > mensagem, ela anda meio parada (ou parada e meia ). > > Mea culpa, mea culpa, mea maxima culpa. > > Por outro lado, ela foi criada numa época em que, lá no Yahoo!, > algumas pessoas reclamaram das discußões conceituais e da gente querer > ensinar o melhor. Como eßa época paßou, não vejo mal algum em > retomarmos eßas discußões aqui. Ótimo. > > > Acabei não participando das conversas na outra discussão, mas notei > > que estamos numa mesma encruzilhada. > > Não sabia. Te importas em compartilhar conosco tuas experiências? É que estou envolvido em dois projetos. Um, quase fracassando, onde combinamos fazer o BD o mais ANSI possível, mas decidiram usar .NET e ms sql server e mesmo os que tomaram essa decisão não conhecem as ferramentas. Outro ainda em fase de proposta vai, proposta vem, em uma entidade governamental, que deve usar exclusivamente PostgreSQL, mas terei (provavelmente) que usar diagramas para comunicar com outros (pessoas e/ou setores). >> Não creio que seja absurdo, mas quem fizesse seria considerado >> "herege", pelos "analistas empurra rato", hoje mesmo me >> frustei muito tentando conversar com uma dessas . > Fiquei curioso. Como você descreve um ‘analista empurra-rato’, e > aliás de onde vem eßa expreßão? Do primeiro projeto citado, onde as pessoas que estão fazendo a análise se limitam ao que o erwin ou o jude podem oferecer, tanto que em um deles (creio que o erwin) que é todo por "click", me pediram ajuda por não conseguirem remover um elemento criado, ai descobri que era com (ou +), a expressão é minha mesmo, mas como um desabafo mesmo. > > Aliás, meninas de plantão, vamos melhorar a representação na > Informática… ou é verdade que vocês são tão inteligentes que preferem > áreas com menos pepinos e (ou) maiores recompensas? O fato de ter sido *uma* analista foi pura coincidência, *os* analistas dão o mesmo trabalho. > > > Já sonhei com "algo" no Postgresql em que pudessemos escrever > > relacional e usar alguma parte do SGSB (sem passar por SQL) para > > executar, mas creio que isso seja sonha demais. > > Por quê? > > Difícil sim, nem faço idéia como se poderia começar. > > Na verdade o Postgres original suportava QUEL, uma outra linguagem. > E o ‘primo’ Ingres ainda suporta QUEL. Então imagino que seja viável, > seja criando mais uma interface para o PostgreSQL, seja bifurcando o > projeto. Me lembrei disso, e o ingres foi liberado com uma licença livre, não lembro qual e se continua ou foi apenas uma versão, cheguei a baixa-lo, mas não fui adiante. Se for com o PostgreSQL, seria ideal mais uma interface, era o que tinha em mente. > > > Eu entendi, e posso até *ajudar*, mas como disse, não tenho estrutura > > para iniciar, e no momento, nem tomar frente de muita coisa. > > Nem eu… estou só jogando a idéia para a lista (e os amigos), para > ver o que acham. E aceito idéias sobre como viabilizar. > > > ps.: Não entendi as referências: Dumbo e Jumbo. > > Qual o noßo mascote? Desculpe a vergonha que passei, parece que o dumbo aqui sou eu :) . > > > ps2.: Alguém conhece alguma ferramenta boa para exibir os ".dot" > > gerados pelo Autodoc? Só conheço o dotty, mas não funciona > > Graphviz. Muito bom. Mas na verdade arquivos dot não se abrem, se > usam para gerar diagramas. Eles definem a estrutura, não o diagrama em > si. Obrigado, mas poderia me passar alguma referência, sobre como usa-los? Leandro, tenho recebido alguns caracteres estranhos em suas mensagens, uso o kmail com utf8 como primeira opção, se eles retornarem estranhos, me desculpe por enquanto. []'s -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. --- -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Seg 02 Jul 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: > Em Seg, 2007-07-02 às 12:36 +, Johnny Taylor Faria Chaves escreveu: > > Um, quase fracassando, onde combinamos fazer o BD o mais ANSI possível, > > mas decidiram usar .NET e ms sql server e mesmo os que tomaram essa > > decisão não conhecem as ferramentas. > > ANSI você quer dizer ISO SQL:2003, não? Questão de costume, acabamos dizendo ANSI quando queremos dizer seguindo "os padrões", e aqui em Belo Horizonte quando se fala ISO, a maioria das pessoas pensa em ISO 9000 :(. > > Se for com o PostgreSQL, seria ideal mais uma interface, era o que > > tinha em mente. > > Não sei se é viável. Quando eu era mais ingênuo, cheguei a lançar a > idéia na hackers, não foram muito entusiásticos. Pois é, mas um "fork" seria um (re)trabalho herculeo. -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
>>>Esta é uma idéia bem incipiente, gostaria de discuti-la aqui. >>> Alguns podem achar que é fora do tópico; nesse caso, aceito >>> > sugestões > >>> de onde debatê-la. >>> Acho que essa lista também se destina a discussões mais teóricas, desde que relacionadas de alguma forma ao PostgreSQL. >> Acabei não participando das conversas na outra discussão, mas notei >> que estamos numa mesma encruzilhada. Todos estamos, já pensei várias vezes em começar uma ferramenta de modelagem, mas ponho fé no trabalho do Euler com o PgAdmin. >>>Mas agora o que tem me irritado é o próprio fluxo de trabalho >>> dessas ferramentas. Não são nada práticas, forçando tudo a passar >>> por diagramas. Eu preferiria fazer tudo em texto, e ter diagramas >>> como saídas do processo, não entradas. >>> >> Também gostaria disso, mas não tenho estrutura para iniciar algo >> assim. Também gosto da idéia. Embora trabalhar com diagramas seja interessante, nenhuma ferramenta implementa eles de forma que sejam suficientes para o processo de modelagem. >> Não creio que seja absurdo, mas quem fizesse seria considerado >> "herege", pelos "analistas empurra rato", hoje mesmo me >> frustei muito tentando conversar com uma dessas . >> > Fiquei curioso. Como você descreve um 'analista empurra-rato', e > aliás de onde vem eßa expreßão? Também fiquei curioso, explique por favor. >> Já sonhei com "algo" no Postgresql em que pudessemos escrever >> relacional e usar alguma parte do SGSB (sem passar por SQL) para >> executar, mas creio que isso seja sonha demais. O maior problema seriam as diferenças no tratamento de linhas duplicadas, nulos, e outras diferenças fundamentais. Pois essas partes implicam mudanças no executor, índices e um monte de coisas dentro do banco. A parte de sintaxe me parece mais tranquila, se você estiver disposto a ter um híbrido relacional/sql como produto final não seria tão complicado. > Na verdade o Postgres original suportava QUEL, uma outra linguagem. > E o 'primo' Ingres ainda suporta QUEL. Então imagino que seja viável, > seja criando mais uma interface para o PostgreSQL, seja bifurcando o > projeto. Sim, viável é, mas vale o esforço? Alterar o PostgreSQL para ter uma linguagem relacional me parece muito esforço para pouco resultado (desculpem-me os idealistas). Acho a idéia do Leandro de ter um sistema de modelagem sobre o SGBD mais interessante. Ter um conjunto de ferramentas bem modulares para modelar, gerar diagramas, alterar o modelo físico e fazer o versionamento do banco, seria ótimo. Mas quem sabe usamos UML? (brincadeirinha) -- Diogo Biazus - [EMAIL PROTECTED] Móvel Consultoria http://www.movelinfo.com.br http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Sobre usar outra linguagem com o PostgreSql... Creio que colocar Quel para dentro do PG é inviável. Não digo tecnicamente, mas sim de disponibilidade / tempo / vontade. Uma alternativa que tive idéia lendo o que falaram foi implementar na forma de uma camada intermediária. A mais simples (que seria bem trabalhosa também, creio) seria, por exemplo. Fazer com que Quel rode sobre a máquina virtual do Java (JVM), o Java 6 tem suporte (facilitado) a linguagens de Script, tanto que hoje existe Ruby rodando sobre JVM, suportado pela Sun. Então Alguma alma caridosa Desenvolve o Quel para rodar na JVM. É feito um mapeamento das expressões Quel para obter obter os dados via JDBC. Existe também a alternativa de implementar a SPI do postgresql. Mas essa talvez sirva só para procedures, implementar uma PL/Quel da vida :) http://www.postgresql.org/docs/8.2/interactive/spi.html > > > Já sonhei com "algo" no Postgresql em que pudessemos escrever > > > relacional e usar alguma parte do SGSB (sem passar por SQL) para > > > executar, mas creio que isso seja sonha demais. > > > > Por quê? > > > > Difícil sim, nem faço idéia como se poderia começar. > > > > Na verdade o Postgres original suportava QUEL, uma outra linguagem. > > E o 'primo' Ingres ainda suporta QUEL. Então imagino que seja viável, > > seja criando mais uma interface para o PostgreSQL, seja bifurcando o > > projeto. > > Me lembrei disso, e o ingres foi liberado com uma licença livre, não lembro > qual e se continua ou foi apenas uma versão, cheguei a baixa-lo, mas não fui > adiante. Se for com o PostgreSQL, seria ideal mais uma interface, era o que > tinha em mente. > Leandro, tenho recebido alguns caracteres estranhos em suas mensagens, uso o > kmail com utf8 como primeira opção, se eles retornarem estranhos, me desculpe > por enquanto. > > []'s > > -- > Johnny Taylor Faria Chaves - LUN 157066 > Não combato ou defendo pessoas ou grupos, > Combato ou defendo idéias ou atos. > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
On 6/28/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]> wrote: > No caso, a gente começaria com uma gramática (por exemplo) Tutorial D > ou D4. Talvez usar um derivado de Scheme ou ML para obter mais concisão > e poder programático, creio que já fizeram um SchemeQL ou coisa assim. Leandro, não sei se vc conhece o projeto XCDSQL (XML (en)Coded and Documented SQL)[1]. Talvez seria um bom começo. [1] http://www.xcdsql.org/ -- wallace reis/wreis Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas/LABBI ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Sex 29 Jun 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: > >>Esta é uma idéia bem incipiente, gostaria de discuti-la aqui. > >> Alguns podem achar que é fora do tópico; nesse caso, aceito > > sugestões > > >> de onde debatê-la. > > > > O ideal, seria na bancosdedados, mas, como voce disse em outra > > mensagem, ela anda meio parada (ou parada e meia ). > > Mea culpa, mea culpa, mea maxima culpa. > > Por outro lado, ela foi criada numa época em que, lá no Yahoo!, > algumas pessoas reclamaram das discußões conceituais e da gente querer > ensinar o melhor. Como eßa época paßou, não vejo mal algum em > retomarmos eßas discußões aqui. Ótimo. > > > Acabei não participando das conversas na outra discussão, mas notei > > que estamos numa mesma encruzilhada. > > Não sabia. Te importas em compartilhar conosco tuas experiências? É que estou envolvido em dois projetos. Um, quase fracassando, onde combinamos fazer o BD o mais ANSI possível, mas decidiram usar .NET e ms sql server e mesmo os que tomaram essa decisão não conhecem as ferramentas. Outro ainda em fase de proposta vai, proposta vem, em uma entidade governamental, que deve usar exclusivamente PostgreSQL, mas terei (provavelmente) que usar diagramas para comunicar com outros (pessoas e/ou setores). >> Não creio que seja absurdo, mas quem fizesse seria considerado >> "herege", pelos "analistas empurra rato", hoje mesmo me >> frustei muito tentando conversar com uma dessas . > Fiquei curioso. Como você descreve um ‘analista empurra-rato’, e > aliás de onde vem eßa expreßão? Do primeiro projeto citado, onde as pessoas que estão fazendo a análise se limitam ao que o erwin ou o jude podem oferecer, tanto que em um deles (creio que o erwin) que é todo por "click", me pediram ajuda por não conseguirem remover um elemento criado, ai descobri que era com (ou +), a expressão é minha mesmo, mas como um desabafo mesmo. > > Aliás, meninas de plantão, vamos melhorar a representação na > Informática… ou é verdade que vocês são tão inteligentes que preferem > áreas com menos pepinos e (ou) maiores recompensas? O fato de ter sido *uma* analista foi pura coincidência, *os* analistas dão o mesmo trabalho. > > > Já sonhei com "algo" no Postgresql em que pudessemos escrever > > relacional e usar alguma parte do SGSB (sem passar por SQL) para > > executar, mas creio que isso seja sonha demais. > > Por quê? > > Difícil sim, nem faço idéia como se poderia começar. > > Na verdade o Postgres original suportava QUEL, uma outra linguagem. > E o ‘primo’ Ingres ainda suporta QUEL. Então imagino que seja viável, > seja criando mais uma interface para o PostgreSQL, seja bifurcando o > projeto. Me lembrei disso, e o ingres foi liberado com uma licença livre, não lembro qual e se continua ou foi apenas uma versão, cheguei a baixa-lo, mas não fui adiante. Se for com o PostgreSQL, seria ideal mais uma interface, era o que tinha em mente. > > > Eu entendi, e posso até *ajudar*, mas como disse, não tenho estrutura > > para iniciar, e no momento, nem tomar frente de muita coisa. > > Nem eu… estou só jogando a idéia para a lista (e os amigos), para > ver o que acham. E aceito idéias sobre como viabilizar. > > > ps.: Não entendi as referências: Dumbo e Jumbo. > > Qual o noßo mascote? Desculpe a vergonha que passei, parece que o dumbo aqui sou eu :) . > > > ps2.: Alguém conhece alguma ferramenta boa para exibir os ".dot" > > gerados pelo Autodoc? Só conheço o dotty, mas não funciona > > Graphviz. Muito bom. Mas na verdade arquivos dot não se abrem, se > usam para gerar diagramas. Eles definem a estrutura, não o diagrama em > si. Obrigado, mas poderia me passar alguma referência, sobre como usa-los? Leandro, tenho recebido alguns caracteres estranhos em suas mensagens, uso o kmail com utf8 como primeira opção, se eles retornarem estranhos, me desculpe por enquanto. []'s -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Sex, 2007-06-29 às 15:04 -0300, Euler Taveira de Oliveira escreveu: > Sim, o problema é que a maioria *não* tem a cultura de responder > utilizando *Reply All* para lista de discussão, também porque são poucos > os casos onde o remetente não está cadastrado na lista e para que as > duplicatas sejam evitadas. Mas se todos tiverem de acordo podemos mudar > isso. Comentários? Só para esclarecer, julgo isso útil porque (1) às vezes queremos responder só diretamente ao rementente e (2) porque geralmente o rementente vai receber a resposta direta antes da cópia da lista, assim agilizando o processo. Mas concordo que haverá gente confusa, reclamando… mas como é uma lista técnica, isso *deveria* ser o de menos. -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Leandro Guimarães Faria Corcete DUTRA wrote: > Moderadores, outra choradinha… pelo menos o Evolution não consegue > responder ao remetente, somente à lista. O ideal seria que os > cabeçalhos permitissem responder ou ao remetente, ou à lista, ou a > ambos. > Sim, o problema é que a maioria *não* tem a cultura de responder utilizando *Reply All* para lista de discussão, também porque são poucos os casos onde o remetente não está cadastrado na lista e para que as duplicatas sejam evitadas. Mas se todos tiverem de acordo podemos mudar isso. Comentários? -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Moderadores, outra choradinha… pelo menos o Evolution não consegue responder ao remetente, somente à lista. O ideal seria que os cabeçalhos permitissem responder ou ao remetente, ou à lista, ou a ambos. Em Thu, 28 Jun 2007 22:18:38 +, Johnny Taylor Faria Chaves escreveu: > Em Qui 28 Jun 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: >>Esta é uma idéia bem incipiente, gostaria de discuti-la aqui. >> Alguns podem achar que é fora do tópico; nesse caso, aceito sugestões >> de onde debatê-la. > O ideal, seria na bancosdedados, mas, como voce disse em outra > mensagem, ela anda meio parada (ou parada e meia ). Mea culpa, mea culpa, mea maxima culpa. Por outro lado, ela foi criada numa época em que, lá no Yahoo!, algumas pessoas reclamaram das discußões conceituais e da gente querer ensinar o melhor. Como eßa época paßou, não vejo mal algum em retomarmos eßas discußões aqui. > Acabei não participando das conversas na outra discussão, mas notei > que estamos numa mesma encruzilhada. Não sabia. Te importas em compartilhar conosco tuas experiências? >>Mas agora o que tem me irritado é o próprio fluxo de trabalho >> dessas ferramentas. Não são nada práticas, forçando tudo a passar >> por diagramas. Eu preferiria fazer tudo em texto, e ter diagramas >> como saídas do processo, não entradas. > > Também gostaria disso, mas não tenho estrutura para iniciar algo > assim. Cheguei a pensar em usar o Alphora Dataphor para ißo, mas entre outros problemas ele não suporta o PostgreSQL. > Não creio que seja absurdo, mas quem fizesse seria considerado > "herege", pelos "analistas empurra rato", hoje mesmo me > frustei muito tentando conversar com uma dessas . Fiquei curioso. Como você descreve um ‘analista empurra-rato’, e aliás de onde vem eßa expreßão? Aliás, meninas de plantão, vamos melhorar a representação na Informática… ou é verdade que vocês são tão inteligentes que preferem áreas com menos pepinos e (ou) maiores recompensas? > Já sonhei com "algo" no Postgresql em que pudessemos escrever > relacional e usar alguma parte do SGSB (sem passar por SQL) para > executar, mas creio que isso seja sonha demais. Por quê? Difícil sim, nem faço idéia como se poderia começar. Na verdade o Postgres original suportava QUEL, uma outra linguagem. E o ‘primo’ Ingres ainda suporta QUEL. Então imagino que seja viável, seja criando mais uma interface para o PostgreSQL, seja bifurcando o projeto. > Eu entendi, e posso até *ajudar*, mas como disse, não tenho estrutura > para iniciar, e no momento, nem tomar frente de muita coisa. Nem eu… estou só jogando a idéia para a lista (e os amigos), para ver o que acham. E aceito idéias sobre como viabilizar. > ps.: Não entendi as referências: Dumbo e Jumbo. Qual o noßo mascote? > ps2.: Alguém conhece alguma ferramenta boa para exibir os ".dot" > gerados pelo Autodoc? Só conheço o dotty, mas não funciona Graphviz. Muito bom. Mas na verdade arquivos dot não se abrem, se usam para gerar diagramas. Eles definem a estrutura, não o diagrama em si. -- 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
Re: [pgbr-geral] Modelagem de Dados à la Unix
Em Qui 28 Jun 2007, Leandro Guimarães Faria Corcete DUTRA escreveu: > Esta é uma idéia bem incipiente, gostaria de discuti-la aqui. Alguns > podem achar que é fora do tópico; nesse caso, aceito sugestões de onde > debatê-la. O ideal, seria na bancosdedados, mas, como voce disse em outra mensagem, ela anda meio parada (ou parada e meia :( ). > > Vocês sabem que andei investigando ferramentas de modelagem, e acabei > ficando frustrado. Acabei não participando das conversas na outra discussão, mas notei que estamos numa mesma encruzilhada. ... > > Mas agora o que tem me irritado é o próprio fluxo de trabalho dessas > ferramentas. Não são nada práticas, forçando tudo a passar por > diagramas. Eu preferiria fazer tudo em texto, e ter diagramas como > saídas do processo, não entradas. Também gostaria disso, mas não tenho estrutura para iniciar algo assim. > E tive a idéia maluca de escrever uma > proposta a respeito, mas queria saber se alguém já viu algo assim, ou se > é absurdo. Não creio que seja absurdo, mas quem fizesse seria considerado "herege", pelos "analistas empurra rato", hoje mesmo me frustei muito tentando conversar com uma dessas . > > Para concluir, creio que um sistema assim poderia ser o começo > de coisas muito melhores. Por exemplo, o único SGBDR hoje em produção é > o Alphora Dataphor, que tem algo semelhante não para modelagem de dados > mas para o sistema como um todo: a gente escreve D4 (que é uma D válida) > e os comandos são executados num SGBD SQL (infelizmente ainda não > suporta o Jumbo). Já sonhei com "algo" no Postgresql em que pudessemos escrever relacional e usar alguma parte do SGSB (sem passar por SQL) para executar, mas creio que isso seja sonha demais. > Deu para entender? Eu entendi, e posso até *ajudar*, mas como disse, não tenho estrutura para iniciar, e no momento, nem tomar frente de muita coisa. ps.: Não entendi as referências: Dumbo e Jumbo. ps2.: Alguém conhece alguma ferramenta boa para exibir os ".dot" gerados pelo Autodoc? Só conheço o dotty, mas não funciona :) -- Johnny Taylor Faria Chaves - LUN 157066 Não combato ou defendo pessoas ou grupos, Combato ou defendo idéias ou atos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Modelagem de Dados à la Unix
Esta é uma idéia bem incipiente, gostaria de discuti-la aqui. Alguns podem achar que é fora do tópico; nesse caso, aceito sugestões de onde debatê-la. Vocês sabem que andei investigando ferramentas de modelagem, e acabei ficando frustrado. Pelo que olhei e até testei, as ferramentas ‘profissionais’ estão por volta de US$4K, chegando facilmente a US$8K se a gente quiser ‘luxos’ (¡não!) como versionamento. As ferramentas livres são inexistentes, incompletas e (ou) imaturas; escolha pelo menos dois desses adjetivos. Além de falta de suporte a sistemas livres e vai por aí afora. Mas agora o que tem me irritado é o próprio fluxo de trabalho dessas ferramentas. Não são nada práticas, forçando tudo a passar por diagramas. Eu preferiria fazer tudo em texto, e ter diagramas como saídas do processo, não entradas. E tive a idéia maluca de escrever uma proposta a respeito, mas queria saber se alguém já viu algo assim, ou se é absurdo. Hoje, numa ferramenta de modelagem de dados, o processo começa com a definição de um dicionário de dados. Usando esse dicionário de dados, cria-se um Diagrama de Entidades e Relacionamentos, DER. Esse diagrama é então traduzido para o sabor SQL do SGBD relevante. O problema óbvio é que diagramas são menos expressivos e mais chatos de fazer que um programa SQL ou (idealmente) relacional. Então por que não escrever ISO SQL, Tutorial D ou mesmo D4 (desculpem os idealistas, também sou idealista mas…)? Não seria fácil, mas creio que seria possível, com planejamento e paciência, criar um sistema muito mais produtivo e flexível usando a filosofia Unix: cada tarefa deve ser bem feita por um componente. As interfaces são bem definidas, e cada ferramenta pode ser substituída ou melhorada independentemente. No caso, a gente começaria com uma gramática (por exemplo) Tutorial D ou D4. Talvez usar um derivado de Scheme ou ML para obter mais concisão e poder programático, creio que já fizeram um SchemeQL ou coisa assim. Mas talvez um subconjunto do ISO SQL:2003, deixando de lado tudo o que for físico como ponteiros, índices &c; embora eu não creia que o SQL seja suficientemente expressivo de todas as situações com que um SGBD deva lidar — especificamente, todos os tipos de restrições de integridade. Nessa linguagem, definiríamos domínios, entidades, regras de negócio &c, tudo o que tem a ver com o modelo lógico (conceitual). O básico é ter a linguagem definida; a partir daí criam-se validadores e compiladores. O resultado dos compiladores seria um programeta (/script/) de definição de dados para o(s) SGBD(s) alvo de escolha, por exemplo nosso caro Dumbo. Dessa mesma definição, usaríamos um AutoDoc ou SQL Fairy (cuidado, a página inicial dele cega!) para gerarmos todos os diagramas que quiséssemos: DER, IDEFIX &c para benefício dos usuários. Até aí é trabalho do Administrador (ou Arquiteto) de Dados. A partir da linguagem, podemos criar todo tipo de auxílios, como IDEs (um modo Emacs, por exemplo). Até aí foi conceitualmente tranqüilo. O que me preocupa, além da possibilidade dessa idéia ser muito pior do que me parece, é o segundo passo: findo o trabalho do AD, começa o do Administrador de Bases de Dados, o sempre popular ABD (ou DBA, para os anglófilos). Ele teria de pegar essa definição da Base de Dados (BD) e acrescentar tudo o que é físico: índices, parâmetros de armazenamento &c. Não me parece especialmente difícil; ele poderia fazê-lo seja numa extensão da nossa linguagem conceitual, seja na linguagem do sistema alvo. Ou mesmo através de remendos (/patches/) a aplicar ao modelo conceitual, como se faz em programação tradicional mesmo. Tenho certeza de que há muitos percalços nos quais não pensei, mas queria saber de vocês o que acham. Para concluir, creio que um sistema assim poderia ser o começo de coisas muito melhores. Por exemplo, o único SGBDR hoje em produção é o Alphora Dataphor, que tem algo semelhante não para modelagem de dados mas para o sistema como um todo: a gente escreve D4 (que é uma D válida) e os comandos são executados num SGBD SQL (infelizmente ainda não suporta o Jumbo). É um sistema proprietário e complexo, e ainda por cima em MS .Net, mas é uma boa idéia. Não consigo imaginar hoje um projeto dum /clone/ ou equivalente livre dele, mas esse nosso sistema eventualmente poderia ser um primeiro passo. Deu para entender? -- 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 mens
