[pyar] OFFTOPPIC - Diseño de Base de Datos y rendimiento

[Roberto Bozzacchi]

Encarar un proyecto desde el análisis y diseño de la base de datos, es algo
del siglo pasado.
Actualmente se realiza el análisis desde UML 2.0 o superior.
De esta forma, desde los casos de uso uno puede elaborar un diagrama de
clases.
Al tener el diagrama de clases, recién ahí uno puede pensar en el artefacto
y capa de datos que da al diseño del DER (Diagrama Entidad Relación) que no
es ni más ni menos que el diseño de la base de datos.

La existencia o no de una base de datos actual, es meramente *anecdótico *y
a veces luego del Análisis realizado y con los casos de uso definidos, la
misma se deberá adecuar al proyecto.

Al menos de esta forma estamos trabajando nosotros. Utilizando el
Enterprise Architect [0] para el seguimiento de los proyectos. Pero sé que
en el mundo libre, hay otros productos de similares características.


[0] : http://www.sparxsystems.com.ar/products/ea/downloads.html


El 19 de febrero de 2013 09:35, Rafael E. Ferrero
<rafael.ferrero en gmail.com>escribió:

>
> El 18 de febrero de 2013 19:53, Carlos Miguel FARIAS <
> carlosmiguelfarias en gmail.com> escribió:
>
> Con la potencia que tienen los SGBD actuales (y hasta en los viejos DBFs)
>> agregar una tabla mas de tipos de proveedores deja el modelo completamente
>> flexible. Un esquema fijo (tipo 1, tipo 2, tipo 3 y nada más) puede parecer
>> simple, pero es un arreglo fijo, una tabla es un arreglo flexible.
>> El cuello de botella en acceso a bd, lo da o el canal de comunicación
>> (que lo solucionas reduciendo el volumen de datos a transferir,
>> seleccionando solo las columnas requeridas, transfiriendo solo los
>> registros que el usuario podrá consultar) o poca memoria en el servidor,
>> que no permita que el SGBD cachetee las tablas en RAM que son muy
>> consultadas.
>> Saludos: Miguel, La Pampa (RA)
>>
>> El 18 de febrero de 2013 19:32, Andrés Gattinoni <
>> andresgattinoni en gmail.com> escribió:
>>
>>> 2013/2/18 Rafael E. Ferrero <rafael.ferrero en gmail.com>
>>>
>>> Hace poco en el chat de pyar tiré una pregunta y me dieron una punta
>>>> para seguir.
>>>> Tengo que repensar una base de datos (bah! una base de archivos dbf
>>>> vieja, cero normalización) el tema es que en la empresa se tienen varios
>>>> tipos de proveedores y de cada tipo se guarda información específica a cada
>>>> uno, a su vez, como es obvio, cada proveedor tiene los datos comunes a todo
>>>> proveedor como su razón social, cuit, etc... me dijeron:
>>>> Generalización/Especialización en la base de datos y WUAAAA!!! me abrió la
>>>> mente pero ahora me resulta sumamente tentador para usar en varios aspectos
>>>> de la aplicación y no se como eso puede influír en la base de datos
>>>> firebird !! es para bien? es para mal?
>>>>
>>>> El tema es que me pasa también con los artículos que se facturan... un
>>>> par de esos artículos son un mundo aparte, no es que se facturen clavos y
>>>> tornillos es una empresa de servicios y hay dos o tres servicios que tienen
>>>> su propia tabla con un montón de info (que tengo que normalizar a full) y
>>>> se me ocurre también hacer la especialización en artículos, idem para
>>>> clientes, etc, etc, etc y no se que tanto me va a complicar los procedure
>>>> sql y tampoco que tanto me va a ralentizar las búsquedas, etc
>>>>
>>>> Alguno tiene experiencia en esto que me pueda brindar para tener idea
>>>> en la que me estoy metiendo ??
>>>>
>>>> Generalización y Especialización sé que es, pero hacerlo en la base de
>>>> datos no me daba idea como hacerlo hasta que encontré la forma en un blog,
>>>> lo postee en el chat porque quién me tiro la punta no sabía como hacerlo en
>>>> la base de datos.
>>>> Hice una tabla Proveedores, Tipos_Proveedores y las tablas Proveedor_1,
>>>> Proveedor_2 ... Proveedor_n donde el Primary Key de la tabla
>>>> Proveedor_1,2,n es la Primary Key de la tabla Proveedores, tal vez alguien
>>>> de acá con más experiencia me pueda indicar si esta bien o esta mal, donde
>>>> fallo, si los selects pueden ser más lentos por el hecho de usar esta
>>>> técnica, etc, etc.
>>>>
>>>> CUALQUIER AYUDA U OPINIÓN EN BIENVENIDA !!
>>>>
>>>
>>> No tengo la posta de nada, pero a modo de opinión creo que te serviría
>>> que pensar dos cosas:
>>>
>>> 1) De qué cantidad de tipos de proveedores distintos estamos hablando?
>>> Es algo que puede variar mucho con el tiempo o que permanecería más o menos
>>> estable? Porque si los tipos distintos son pocos (digamos, 5) podés
>>> resolverlo de una manera que implique un esquema un poco más rígido pero
>>> queries más fáciles y rápidas, y sino vas a necesitar un esquema mucho más
>>> flexible donde las queries se pueden poner un poco más complejas (o capaz
>>> deberías pensar en alguna base de datos schema-less).
>>>
>>> 2) Qué tipo de consultas necesitás hacer sobre esos datos? Por ahí
>>> teniendo algunos casos de uso te das una mejor idea de la complejidad que
>>> tendrían las queries. No es lo mismo si las tablas de especialización son
>>> solamente información que mostrás al ver los detalles de un proveedor (y
>>> entonces hacés una query a una tabla a partir de ID de proveedor), que si
>>> tenés que joinear esas tablas en queries más complejas para formar un
>>> listado consolidado de proveedores con sus distintas características (no sé
>>> si esto tendría sentido en algún caso, pero fue lo primero que me vino a la
>>> mente jajaja).
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> pyar mailing list pyar en python.org.ar
>>> http://listas.python.org.ar/listinfo/pyar
>>>
>>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>>
>>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>>> Argentina - http://www.usla.org.ar
>>>
>>
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
> Claro, específicamente es así el modelo:
>
> Tengo una tabla con los datos básicos de Proveedores y tres tablas
> específicas para Médicos, Clínicas y Farmacias... los datos que se desean
> de estas tres exceden los datos básicos y comunes a todos los proveedores.
> Cada una tiene sus propios datos que son independientes de los demás. Estos
> tipos específicos de proveedores no va a cambiar en el corto o mediano
> plazo (y me atrevo a decir que nunca lo hará). Pero los datos que se
> necesitan de un Médico no son los de una Clínica y mucho menos de la
> empresa que nos hace los services de Aire Acondicionado (se entiende no?)
>
> De igual forma dos artículos que se facturan normalmente son Cuotas
> societarias y otros son Coseguros, pero también hay otros ítems cuyos datos
> son comunes, es por ello que también pensé en tener una tabla Artículos (o
> Conceptos, o llámenla como quieran) como padre y Cuotas y Coseguros como
> hijos con sus datos específicos.
>
> Dada mi escasa experiencia en este tópico en particular es que consulto
> qué tanto y en qué aspecto es contraproducente o no realizar este enfoque.
>
> (Reitero, particularmente usamos bases de datos Firebird. Los Inserts y
> Updates son todos Procedures de Firebird).
>
> Saludos
>
>
> --
> Rafael E. Ferrero
> Claro: (03562) 15514856
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



-- 

Robbie Bozzacchi
Metasigno Brain
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130219/026eb239/attachment.html>