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

[Rafael E. Ferrero]

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