Re: [pgsql-es-ayuda] Separación lógica de tablas, agrega rendimiento?

Si tiene indices, la tabla de movimientos apunta a la caja de material, la
caja de material apunta al material en sí y el material al cliente.
Todo está bien indexado, se ejecutan vacums periodicamente, cada año se
realiza un drop y se vuelve a cargar la información. El sistema no es
grande, es pequeño pero el volumen de información que se maneja es altísimo
en comparación de todos los demás sistemas que he hecho, a 11 años de su
creación iria por los 150 gigas, pero por ahi del 2010 se eliminaron todos
los registros muertos y actualmente va en casi 90 gigas. El número total de
clientes son alrededor de 50, no creo que algun dia vaya a tener miles de
clientes. Tampoco es un sistema de alta concurrencia, los dos primeros
turnos son lo más pesados con alrededor de entre 20 u 30 usuarios y el
turno de la noche alrededor de 5. Estos usuarios tampoco están pegados al
sistema.
Mi pregunta era si hacer tablas hijas es equivalente a tener tablas en
diferentes schemas. Yo veo mas viable reprogramar a tener tablas en
diferentes schemas que tablas hijas.
Aunque igual, pudiera mantener una sola tabla como he venido haciendo, es
solo que si se puede incrementar algo de performance separando en schemas,
me gustaría hacerlo.

Saludos y gracias por sus comentarios.

2016-04-19 14:41 GMT-05:00 Hellmuth Vargas <hivs77(at)gmail(dot)com>:

> Hola Ivan
>
> PostgreSQL esta en capacidad de forma 'automática' los diferentes tablas
> que hacen parte de la un partición, el tema del procedimiento es que si
> diseña bien la clave de partición la definición del Procedimiento es
> sencillo y de mantenimiento muy espaciado en el tiempo (incluso puede ser
> hasta nulo). Incluso existen extensión que definen y crean todo lo
> necesario para la definición y gestión de particiones (por
> ejemplo pg_pathman por mencionar una reciente publicada). La potencia del
> tema es que una vez definido, es prácticamente transparente, pues es el
> motor se encarga de seleccionar la partición apropiada tanto para las
> operaciones DML como para las consultas. Vuelvo y reitero, el asunto es
> definir claramente la clave de partición, ojala qeu permita que la
> informacion se distribuya uniformemente entre las particiones, las
> consideraciones son variadas, las tablas tiene fecha de creación? se
> pueden crear particiones mensuales, ademas puede participarse por cliente?
> (clave compuesta)...
>
> El 19 de abril de 2016, 14:07, Ivan Perales M.<ivan(dot)perales(at)gmail(dot)com>
> escribió:
>
>> Que tal buenas tardes.
>>
>> Me gustaria su opinion sobre lo siguiente. Hace varios años que se hizo
>> un sistema para logistica de material. Con el paso de los años, dos tablas
>> principales crecieron al grado de tener millones de registros, una es la
>> que representa cada caja de material y la otra es los movimientos de
>> material.
>>
>> El sistema obviamente es para muchos clientes, por lo que cada tabla
>> tiene registros de todos los clientes y una columna que los indentifica. Y
>> como en todo negocio, hay clientes chicos y clientes grandes. Clientes que
>> manejan tan poco volumen que sus movimientos llegan a varios miles y otros
>> con varios cientos de miles.
>>
>> Cuando se hace una consulta para un cliente pequeño en esas tablas, el
>> tiempo del query es mucho mayor a que si solo buscara en los registros
>> propios del cliente y esto es obvio, es por que tambien busca entre los
>> registros de los otros clientes.
>>
>> Buscando en internet como optimizar esto, encontre un blog que decia que
>> para optimizar el rendimiento de tablas grandes se deberia utilizar la
>> partición de tablas, que básicamente son muchas tablas hijas, donde un
>> store procedure decide a que tabla hija enviar la información.
>>
>>
>> Mi pregunta es, si creo un schema para cada cliente teniendo las mismas
>> tablas, entonces esta separación logica trabajaria igual que la particion
>> de tablas no? la diferencia es que seria desde el software donde se indique
>> a que schema guardar y no mediante un store procedure. Realizar esta
>> separación realmente si trae ventajas en lugar de utilizar una sola tabla
>> para todos los clientes?
>>
>> Saludos y gracias por su tiempo.
>>
>> --
>> Lindolfo Iván Perales Mancinas
>> Solo existen 10 tipos de personas en el mundo, las que saben binario y
>> las que no.
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>

--
Lindolfo Iván Perales Mancinas
Solo existen 10 tipos de personas en el mundo, las que saben binario y las
que no.