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

[Carlos Miguel FARIAS]

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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130218/1fe8c308/attachment.html>