Mi preferida es PgModeler. Mucho tiempo usé Power Architect, que es superior a PgModeler en algunas cosas; sobre todo la interfaz es más veloz y los diagramas quedan más limpios y son más fáciles de reacomodar, pero PA tiene bugs e incompatibilidades, ya que no está dirigido específicamente a Postgres; yo he tenido que escribir scripts que me permitan explotar características de Postgres que PA no me permite, y otros para darle la vuelta a errores de programación internos a PA. Otras cosas las he tenido que parchar en el código en Java, pero como sea el proyecto parece estar muerto porque no hay una comunidad de desarrolladores alrededor de la aplicación.
Con PgModeler puedes actualizar automáticamente una BD en vivo y tal, aunque tiene sus bugs. No lo recomendaría para un proyecto ya muy grande. Su formato de salida es XML, y puede ser un desastre para integrar con sistemas de control de código como git, especialmente con un equipo de trabajo mediano en adelante con varios desarrolladores metiéndole a la estructura al mismo tiempo, etc. Mi recomendación sería usar PgModeler para guardar estructura de BD, vistas, dominios, tipos de datos, que son cosas que no tienden a cambiar mucho y generalmente se requiere un consenso antes de proceder, pero si vas a hacer un uso extenso de triggers y/o funciones, mejor guardar eso en scripts SQL aparte y no guardarlos en el XML de PgModeler. Está padre eso del autodoc para diccionarios de datos... La ventaja de crear un diagrama a mano es que es posible hacer que la parte conceptual se vea reflejada gráficamente en el diagrama. Un algoritmo para grafos obviamente no va a entender estos conceptos y hará un esfuerzo por presentar bien su grafo, pero no va a poder darle la estética o sentido humano que un diagrama bien hecho podría tener; por ejemplo, cuando un conjunto de propiedades opcionales que se normalizaron debidamente de una tabla "madre" mayor, estas tablas de propiedades se pueden colocar de manera satelital alrededor de la madre, reflejando su naturaleza opcional o aditiva. Creo que el diagrama debe ser la fuente, y el SQL los productos de este, y no al revés. Hay aspectos del diagrama que es complicado inferir a partir del modelo físico puro. Saludos, Arturo 2017-05-11 21:21 GMT-05:00 Nahum Castro <nahumcas...@gmail.com>: > Gracias Gunnar. > > Probando... > > El 11 de mayo de 2017, 11:34, Gunnar Wolf<gw...@debian.org> escribió: > >> Los observadores de entre ustedes pueden haberse dado cuenta que me >> equivoqué de lista al presentar el ejemplo del hilo en esta >> lista... Bueno, no tiene mayor importancia, espero que los >> participantes en cuestión no se molesten de haber sido empleados como >> ejemplo. >> >> Pero lo que sí debí haber mencionado es que... Volviendo al >> planteamiento original de Abel: >> >> > > Estoy buscando un editor de diagramas (en particular DERs), Código >> Libre, >> > > que pueda ejecutarse sobre Linux, Windows y Mac, y preferentemente >> que sea >> > > exportable a otras herramientas y/o que el archivo no sea binario. >> >> Si lo que quieres es una herramienta para sentarte a planificar >> gráficamente una BD, lo siguiente no reviste mayor importancia. Pero >> para diagramar una BD en PostgreSQL, es sencillamente _genial_: >> ¿Conoces postgresql_autodoc? >> >> http://www.rbt.ca/autodoc/ >> >> Es una herramienta que genera documentación a partir de una BD viva, y >> la documenta (o genera plantillas para que tú las completes) en varios >> formatos. Va acá un ejemplo de una BD mía: >> >> https://www.data.gwolf.org/krdb/ >> >> Uno de los formatos de exportación (dos, de hecho), claro, es >> Graphviz. Los archivos fuentes, keyring.dot y keyring.neato. Los >> compilados, ambos tanto en SVG como PNG. >> >> Saludos >> >> - >> Enviado a la lista de correo pgsql-es-ayuda ( >> pgsql-es-ayuda@postgresql.org) >> Para cambiar tu suscripción: >> http://www.postgresql.org/mailpref/pgsql-es-ayuda >> > > > > -- > *Nahum Castro González* > Blvd. Perdigón 214, Brisas del Lago. > CP 37207 > León, Guanajuato, México > Tel (477)1950304 > Cel (477)1274694 >
