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

[Andrés Gattinoni]

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