2011/9/20 Guimarães Faria Corcete DUTRA, Leandro <lean...@dutras.org>:
> 2011/9/20 Leonardo Cezar <lhce...@gmail.com>:
>>
>> Aqui na empresa
>
> Dataprev?
Sim.
>> estamos revisando alguns procedimentos e adquirindo
>> uma ferramenta (a licitar..), porque eu nunca encontrei uma solução
>> que atenda minimamente os requisitos de modelagem dentro dum fluxo
>> corporativo onde existem várias caixinhas pra isso e praquilo...
>
> Queres dizer, livre?
Não mais. Até onde sei, não existem ferramentas livres que atendam os
nossos requisitos.
>> O autodoc está defasado, gera gráfico pobres (baseado em graphviz) e
>> não creio que atenda algo mais complexo.
>
> Cara, Graphviz é muito bom… e livre! Só de não ter de ficar horas e
> horas arrastando caixinha… na minha experiência, ele sempre criou
> diagramas muito melhores (e mais facilmente) que qualquer algoritmo de
> qualquer outra ferramenta… ou estou redondamente enganado?
Está redondamente enganado.
> Tenho medo de não alcançar o entendimento do que crês que ele não
> antederá, por isso não pergunto…
Se insistir, explico onde erramos no autodoc, mas precisaria resgatar
os códigos e as diversas tentativas de evoluções daquele código.
>> - Oracle Design (sux*100)
>
> Abandonado, certo?
Pela Oracle, sim, mas para uma empresa que ainda tem cerca de 90% de
seus sistemas armazenados dentro dele, não.
>> - Data Architect (bom e proprietário)
>
> Esse é o da IBM? Se fôr, última vez que olhei era muito gordo e muito
> caro, isso mudou?
Não é.
> Para mim, a decisão é simples: se tenho de manter uma biblioteca de
> modelos numa única ferramenta para modelos que serão implementados,
> cada um, em vários SGBDs diferentes, aí preciso duma dessas
> ferramentas que misturam modelagem e diagramação.
É o caso da maioria, acredite.
A questão não se limita a modelagem; apenas pra citar 15 dos mais de
40 requisitos necessário em nosso ambiente:
* Possibilidade de criar o DER a partir do modelos lógicos
(diagrama de entidades)
* Criação automático do Mapeamento Objeto Relacional e, mais
especificamente, dos mapeamentos do JPA
* Utilizar repositório único e integrado
* Garantir versionamento dos objetos existentes no repositório
* Capacidade de mapeamento de re-uso de objetos
* Garantir rastreabilidade de uso dos objetos, para análise
* Compatibilidade entre tipos e domínios
* Integração de repositórios com a base física
* Geração de DDLs/SQL
* Geração de Sequences
* Geração de índices
* Comparação (diff) entre esquemas
* Versionamento da estrutura
* Rastreabilidade de dependência (relacionamentos)
> Mas, se tenho o
> privilégio de mexer só com PostgreSQL, então programação SQL literária
> com noweb ou algo parecido, gerando gráficos com AutoDoc, é o que
> chamo de modelagem literária e é muito bom…
Se tem esse privilégio, vc é um baita sortudo!
-Leo
--
Leonardo Cezar
http://postgreslogia.wordpress.com
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
