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.p...@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 (gvm2...@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@python.org >> https://mail.python.org/mailman/listinfo/python-es >> > > > -- > -------------------------------------- > fp...@mapologo.org.ve > francisco.p...@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@python.org > https://mail.python.org/mailman/listinfo/python-es >
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es
