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
