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

2019-05-23 Por tema Jose Antonio Pérez Pérez 
Que es lo que buscas en concreto?
Tiene que estar hecho en Django necesariamente? Podrias usar PonyORM ,
tiene una herramienta de diseño de datos, pero tendrias que aprender un ORM
nuevo y muy distinto que el de Django. Aun asi te lo recomiendo por lo
interesante que resulta.

El vie., 3 may. 2019 a las 3:58, Gonzalo V () 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
>
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es

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

2019-05-21 Por tema 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
.* 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*
 según tu conveniencia y necesidades.

Dtb/Gby
===
Mario R. Osorio
B.A.S. of Information Technology
Web page: *http;//mario.osorio.solutions
*
Email: *mario@osorio.solutions* 
*Just Choose Python!* 

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



On Tue, May 21, 2019 at 1:35 PM Gonzalo V  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.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,
>>>

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

2019-05-21 Por tema Gonzalo V 
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 ()
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

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

2019-05-03 Por tema Francisco Palm 
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

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

2019-05-03 Por tema AGTUGO 
No termino bien de entender tu pregunta


On Fri, May 3, 2019 at 12:52 AM Pau Cervera  wrote:

> Buenas,
>
> Django adopta una aproximación en la que se define la capa de persistencia
> a partir de classes de python y luego el mismo framework genera, a partir
> de estas definiciones de classes, el schema de la base de datos . Django
> incluye también tooling para aplicarlo.
>
> Es más, el tooling está diseñado para que el modelo vaya evolucionando y a
> partir de él se puedan ir generando las nuevas tablas o se modifiquen las
> que ya existen e incluye soporte para añadir datos en caso necesario.
> Django llama a estos flujos migrations [1].
>
> El flujo general es diseñar modelo de objetos -> crear migración ->
> aplicar migración.
>
> Los paquetes de terceros de django y los de aplicaciones de soporte
> (p.ej.: django.contrib.auth) usan también este sistema, así que si vas a
> usar django, lo suyo es aprender cómo funciona su propio ORM.
>
> El tutorial de django [2] explica esto paso a paso.
>
> [1] https://docs.djangoproject.com/en/2.2/topics/migrations/
> [2] https://docs.djangoproject.com/en/2.2/intro/tutorial01/
>
> Saludos,
>
> -
> Pau
>
> Python..., what else?
>
>
> On Fri, May 3, 2019 at 4:58 AM Gonzalo V  wrote:
>
>> 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
>>
> ___
> Python-es mailing list
> Python-es@python.org
> https://mail.python.org/mailman/listinfo/python-es
>


-- 
Arturo Muñoz Tolosa
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es

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

2019-05-03 Por tema Pau Cervera 
Buenas,

Django adopta una aproximación en la que se define la capa de persistencia
a partir de classes de python y luego el mismo framework genera, a partir
de estas definiciones de classes, el schema de la base de datos . Django
incluye también tooling para aplicarlo.

Es más, el tooling está diseñado para que el modelo vaya evolucionando y a
partir de él se puedan ir generando las nuevas tablas o se modifiquen las
que ya existen e incluye soporte para añadir datos en caso necesario.
Django llama a estos flujos migrations [1].

El flujo general es diseñar modelo de objetos -> crear migración -> aplicar
migración.

Los paquetes de terceros de django y los de aplicaciones de soporte (p.ej.:
django.contrib.auth) usan también este sistema, así que si vas a usar
django, lo suyo es aprender cómo funciona su propio ORM.

El tutorial de django [2] explica esto paso a paso.

[1] https://docs.djangoproject.com/en/2.2/topics/migrations/
[2] https://docs.djangoproject.com/en/2.2/intro/tutorial01/

Saludos,

-
Pau

Python..., what else?


On Fri, May 3, 2019 at 4:58 AM Gonzalo V  wrote:

> 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
>
___
Python-es mailing list
Python-es@python.org
https://mail.python.org/mailman/listinfo/python-es