[Python-es] Programa para diseñar la base de datos

[Mario R. Osorio]

Para un proyecto en el que trabajé recientemente, analizamos mas de una
docena de productos, tanto de código abierto como servicios y productos
pagados. La idea era poder trabajar con postgresql, mssql y mysql, en ese
orden de importancia. Nuestra conclusión: *vertabelo
<https://www.vertabelo.com/>.* Ninguno otro llegó ni remotamente cerca a
ofrecer las ventajas que vertabelo ofrece. Los precios podrían ser mejores
pero en honor a la verdad; están solos en esa categoría y se pueden dar ese
lujo.

No te quiero hablar de todas sus ventajas para no convertir este mensaje en
una publicidad. Pero vertabelo te permite desarrollar tu base de datos y te
entrega, ademas de los graficos necesarios; el código para crear la base de
datos misma. Te adelanto si, que incluir triggers en tu código podría
resultar un poquito complicado, pero muy posible. Recuerda que los triggers
deben ser el único comando en un lote (batch) así que tienes que envolver
el comando entre sentencias go. Eso precisamente podría resultar en un reto.

Dicho todo eso, y si vertabelo no está dentro de tus posibilidades, aún
puedes utilizar MySQL workbench y *convertir el código*
<http://www.sqlines.com/online> según tu conveniencia y necesidades.

Dtb/Gby
=======
Mario R. Osorio
B.A.S. of Information Technology
Web page: *http;//mario.osorio.solutions
<http://http%3B//mario.osorio.solutions>*
Email: *mario en osorio.solutions* <mario en osorio.solutions>
*Just Choose Python!* <http://www.gentoogeek.org/files/choose_python.pdf>

*SQL programmers don't die, they just ROLLBACK the TRANSACTION.*



On Tue, May 21, 2019 at 1:35 PM Gonzalo V <gvm2121 en gmail.com> wrote:

> Bienvenido tu artículo Francisco Palm, así todos aprendemos más.
> Yo entiendo el modelo ORM y lo uso y funciona, mi pregunta apuntaba a la
> forma gráfica de interrelacionar tabla antes de sentarse de programar el
> models.py, creo que access tenía algo gráfico y workbench también pero
> buscaba algo con prosgres.
> Creo que, por el momento, ensayo y error funcionan bien.
>
> Saludos,
> Gonzalo
>
>
> El vie., 3 may. 2019 a las 22:08, Francisco Palm (<
> francisco.palm en gmail.com>) escribió:
>
>>
>> Saludos
>>
>> Te recomiendo algo, yo he pasado por esto muchas veces.
>>
>> Piensa el modelo de datos junto con las interfaces. Supongo que has leído
>> de los mockups. Las dos cosas están fuertemente relacionadas.
>> Cuando te encuentras en un formulario donde tienes un combo donde vas a
>> seleccionar un valor entre varias opciones, ahí tienes un ForeignKey.
>> Cuando estás delante de una vista donde tienes varios valores en un
>> componente. Por ejemplo, los distintos libros/artículos que ha escrito
>> alguien, estás delante de una relación de muchos a muchos.
>> Si por temas de diseño, tiene una situación en la que tienes que
>> enlazarte a otro valor de una forma unívoca, una persona tiene un único
>> perfil, tiene una relación de uno a uno.
>> Luego las restricciones, si es uno o más, o cero o más, etc. Eso va en la
>> lógica de negocio y en los modelos. Cuando es básico, como decir si un
>> campo es obligatorio o no es parte de la definición del modelo, pero si la
>> restricción es más compleja y depende de la interacción con el usuario,
>> probablemente lo indicarás en la vista.
>>
>> Vale la pena considerar que esos "atajos" que ahorra tiempo de escritura
>> al usuario, suelen estar ligados a la normalización del modelo. El usuario
>> no tiene porque escribir algo que el sistema ya tiene almacenado, como el
>> nombre de un país, una provincia, un municipio, el nombre del cine del que
>> quiere conocer la cartelera, etc.
>>
>> Es mucho ensayo y error, y por eso el comentario de las migraciones es
>> adecuado. Vas cambiando el modelo y aplicas las migraciones. Pero aunque
>> las migraciones se ejecuten correctamente puede quedar rota la lógica de
>> negocio.
>>
>> Casi todos necesitamos ver el modelo, para eso tienes la funcionalidad
>> graph models de la extensión django-extensions, Se trata de cambiar el modo
>> de pensar, del modelo de Word al modelo de LaTeX o Markdown, no es que "lo
>> que escribes es lo que ves" (WYSIWYG), sino "lo que escribes es lo que
>> significa" (WYSIWYM). Y de esta manera es mucho más poderoso, porque con
>> graph models tienes la representación de tu modelo -funcional-. Mientras
>> con una herramienta de modelado gráfico, si tienes que cambiar el modelo,
>> qué tendrás que hacerlo infinidad de veces. No he conocido una herramienta
>> de modelado que funcione en las dos direcciones (diseño <-> modelo) sin
>> limitaaciones, a lo sumo te sirve para algunas iteraciones similares,
>> mientras generar una representación del modelo funcional -siempre- te va a
>> funcionar.
>>
>> Creo que debería escribir un articulito sobre esto.
>>
>> Saludos
>>
>> F. Palm
>>
>>
>>
>> El jue., 2 de may. de 2019 a la(s) 22:58, Gonzalo V (gvm2121 en gmail.com)
>> escribió:
>>
>>> Hola amigos.
>>> Alguien conoce algún programa para diseñar la base de datos antes de
>>> comenzar un proyecto en django - python?
>>>
>>> Saludos,
>>> Gonzalo
>>> _______________________________________________
>>> Python-es mailing list
>>> Python-es en python.org
>>> https://mail.python.org/mailman/listinfo/python-es
>>>
>>
>>
>> --
>> --------------------------------------
>> fpalm en mapologo.org.ve
>> francisco.palm en gmail.com
>>
>> cel: +58 +424 7228252
>> tel: +58 +274 6352001
>>
>> ----
>> Debemos ser libres, no para hacer lo que nos plazca, sino libres para
>> comprender muy profundamente nuestros propios instintos e impulsos. K
>> _______________________________________________
>> Python-es mailing list
>> Python-es en python.org
>> https://mail.python.org/mailman/listinfo/python-es
>>
> _______________________________________________
> Python-es mailing list
> Python-es en python.org
> https://mail.python.org/mailman/listinfo/python-es
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20190521/624c8a50/attachment.html>