Hola a todos,
No sé si el título encaja bien con lo que os voy a contar, pero no se me ocurría otro mejor.
En mi empresa estamos trabajando en la construcción de un nuevo sistema de gestión de recursos humanos. Partimos de un software difícil de mantener que ya se encuentra en producción y que nos ha entregado el cliente como referencia.
Soluciones? Ideas? Preguntas?
Thx y sorry por el tochopost.
No entiendo como puede ser que datos tan sencillos ocupen tanto ( además que no deberías fijarte en el tamaño de la BD sino en el numero de Rows que tengan las tablas más usadas de la BD )
Hoy en día 1.5gb no es ná, así que no debería preocuparte, además siendo tablas en las que solo vas a insertar una vez al dia (por ejemplo) pero consultarlas muchas veces a lo largo del dia puedes crear una caché a nivel de aplicación y no debería darte ningún problema ya que no van a cambiar apenas.
#2 pues date cuenta que para cada trabajador se calcula la cifra de lo que cobra cada uno de los días desde que lleva en la empresa.
Simplemente eso ya da: (currando 2 años): 730 filas en una tabla. Si le añades que son 800 trabajadores tenemos: 584000 filas con (id_trabajador, día, sueldo_incremental).
Ahora hay que tener en cuenta de que en vez de ser 800 van a ser 100.000. El tamaño ya importa, y las búsquedas en la tabla empiezan a pesar aunque se introduzca un índice por fecha.
Una caché a nivel de aplicación tampoco soluciona mucho ya que serían muy pocos los datos que se pudiesen almacenar en memoria.
Has probado http://sphinxsearch.com/ ? Vas indexando las tablas que mas problemas te den y las búsquedas y cálculos deberían ser muchísimo más rápidos.
Luego para reindexar con los datos nuevos de la tabla puedes tener un cron que por la noche lo vaya haciendo y no afecta en absoluto al funcionamiento de la aplicación ya que no bloquea tablas etc.
#4 el problema no es que esté funcionando lento. El problema es que con el proceso actual se genera una base de datos demasiado grande en tamaño, que puede llegar a ser inmantenible (los indices además ocupan un huevo).
Si cambio el proceso y decido en vez de almacenar todos los días lo que cobra un trabajador, almacenar sólo los días donde se produce un cambio y después realizar el cálculo "al vuelo", tengo miedo que las respuestas no sean lo suficientemente rápidas, no para un trabajador, sino por ejemplo para un departamento entero, donde habría que hacer los cálculos para un montón de trabajadores a la vez.
#5 Entonces tendrás que adecuar tus tablas y queries para sacar el máximo partido a claves primarias e índices para que tus queries sean lo más rápidas posible.
El problema es que guardar a diario lo que genera un trabajador es lo que te hace que se generen tantos registros. Lo lógico es guardar lo "normal" 1 vez. Por ejemplo, mi sueldo base desde tal a pascual es de 800 € y guardar lo que esté fuera de eso.
De esta forma, en vez de tener 4000000000000000000000000 millones de líneas duplicadas solo tienes 1.
En resumen, es un problema de diseño de base de datos. Y con esto no quiero decir que esté mal diseñada, porque a lo mejor la solución que propongo no es viable. Simplemente hablamos de limitaciones técnicas con el diseño que tienes actualmente.
Hoy hemos tenido una reunión bastante larga en el curro tratando de este tema.
Las conclusiones a las que hemos llegado son:
01/03/2012 -> 45€
02/03/2012 -> 45€
03/03/2012 -> 50€
04/03/2012 -> 100€
05/03/2012 -> 50€
06/03/2012 -> 50€
por esto:
partiendo de un sueldo base 45€:
Tabla Aumentos (fecha, aumento):
03/03/2012, 5€
Tabla Bonificaciones Puntuales (fecha, bonificación):
04/03/2012, 50€
Así ahorramos mucho más espacio aunque luego tengamos que calcular el resto. Es una especie de paso intermedio entre almacenar todo o calcularlo todo al vuelo. El tema es si conseguiremos que de esta forma los cálculos sean lo suficientemente rápidos como para mostrarlos en pantalla en el orden de 1 - 2 segundos.
El ejemplo que he puesto es infinitamente sencillo con la realidad de la aplicación, ya que hay que tener en cuenta como posibles aumentos / bonificaciones cosas como: categorias sindicales, puestos en la empresa, % de dedicacion, aumentos de sueldo, vacaciones, ausencias justificadas e injustificadas, discapacidades, etc.
#9 Todo lo que sean datos repetidos (con el mismo valor) lo suyo es omitirlos.
Por otra parte, el tipo de campo creo que influye también en el tamaño (int en vez de bigint, nvarchar ajustados, ect)
, que es interesante.