Eficiencia
Hola.
Tengo una tabla en SQL Server que necesito que proporcione los datos, y añada registros lo más rápido posible. Otra característica importante de esa tabla es que, aunque en un principio se modifican los registros de algunos campos, luego no se actualizan nunca más.
Mi problema es que quiero realizar búsquedas en los registros que ya no se van a modificar y a la vez, que la tabla sea lo más rápida posible, por lo que se me ha ocurrido mover los registros que ya no se van a cambiar a otra tabla o a otra base de datos.
¿Qué será más eficiente, dejar la tabla como está, mover los registros que ya no se van a modificar a otra tabla, o moverlos a otra base de datos SQL Server?
Si me pudieras comentar un poco los pros y los contras de cada solución, te estaré sumamente agradecido.
Un saludo.
Tengo una tabla en SQL Server que necesito que proporcione los datos, y añada registros lo más rápido posible. Otra característica importante de esa tabla es que, aunque en un principio se modifican los registros de algunos campos, luego no se actualizan nunca más.
Mi problema es que quiero realizar búsquedas en los registros que ya no se van a modificar y a la vez, que la tabla sea lo más rápida posible, por lo que se me ha ocurrido mover los registros que ya no se van a cambiar a otra tabla o a otra base de datos.
¿Qué será más eficiente, dejar la tabla como está, mover los registros que ya no se van a modificar a otra tabla, o moverlos a otra base de datos SQL Server?
Si me pudieras comentar un poco los pros y los contras de cada solución, te estaré sumamente agradecido.
Un saludo.
1 respuesta
Respuesta de inetkali
1
Como en la mayoría de los problemas de este tipo, la solución óptima vendrá condicionada por tu presupuesto, el volumen de los datos, y el tiempo con el que necesites procesar los datos introducidos.
Si la tabla tiene sólo unos miles de registros, y no hay mucha movimiento, no es necesario mover los registros a otra tabla.
Si en cambio, estamos hablando de un sistema en el que se introducen ciento de miles o millones de registros a la semana, y además necesitas hacer consultas exhaustivas posteriores, entonces es recomendable mover los datos que no utilizas y borrarlos de la tabla de entrada.
Si los mueves a otra tabla dentro de la misma base de datos, no ganas mucho, excepto que puedes regenerar los índices y configurarlos para que haya espacio para nuevos registros en la tabla original (con un fillfactor bajo) y en la tabla de consulta, usar un índice de tipo clustered, con un fillfactor alto.
Si los mueves a otra base de datos dentro del mismo servidor, ganarás algo más si la base de datos está en otro disco duro, porque no cargará tanto la entrada de nuevos datos. Aún así si las consultas son extensivas, cargarán mucho al servidor.
La solución para millones de registros y/o consultas extensivas es utilizar otro servidor para la explotación de los datos de entrada.
En cualquier caso, te aconsejo que hagas servir replicación para mover los registros que se han introducido al otro servidor o base de datos, con cierto intervalo de tiempo, de forma automática.
Si la tabla tiene sólo unos miles de registros, y no hay mucha movimiento, no es necesario mover los registros a otra tabla.
Si en cambio, estamos hablando de un sistema en el que se introducen ciento de miles o millones de registros a la semana, y además necesitas hacer consultas exhaustivas posteriores, entonces es recomendable mover los datos que no utilizas y borrarlos de la tabla de entrada.
Si los mueves a otra tabla dentro de la misma base de datos, no ganas mucho, excepto que puedes regenerar los índices y configurarlos para que haya espacio para nuevos registros en la tabla original (con un fillfactor bajo) y en la tabla de consulta, usar un índice de tipo clustered, con un fillfactor alto.
Si los mueves a otra base de datos dentro del mismo servidor, ganarás algo más si la base de datos está en otro disco duro, porque no cargará tanto la entrada de nuevos datos. Aún así si las consultas son extensivas, cargarán mucho al servidor.
La solución para millones de registros y/o consultas extensivas es utilizar otro servidor para la explotación de los datos de entrada.
En cualquier caso, te aconsejo que hagas servir replicación para mover los registros que se han introducido al otro servidor o base de datos, con cierto intervalo de tiempo, de forma automática.
