Sugerencia para un gran diseño de base de datos de SQL Server

Estamos creando una base de datos en MSSQL 2008 R2 Standard donde almacenaremos una gran cantidad de registros. Estimamos más de 200 millones de registros en una tabla anualmente y estamos INSERTANDO principalmente con muy pocas ACTUALIZACIONES o DELETES en los datos. Es un sistema de archivo de datos donde insertamos registros históricos a diario. Generaremos diferentes tipos de informes sobre este registro histórico a solicitud del usuario, por lo que tenemos algunas preocupaciones y requerimos aportes técnicos y asesoramiento.

• ¿Cuál es la mejor manera de administrar este tipo de tablas de archivos y bases de datos?

Aquí está mi opinión:

1. Si tiene muy pocas actualizaciones / eliminaciones, puede aumentar el factor de llenado de página al 95%. Esto ahorrará espacio y lecturas. Sin embargo, haz algunas pruebas.
2. Particione la tabla en función de una categoría amplia como año.
3. Coloque estas particiones en diferentes grupos de archivos.

200 millones de filas por año no son especialmente grandes (a menos que las filas sean inusualmente grandes). Debe prestar atención a los principios de diseño de bases de datos de sonido (normalización) y hacer uso de características estándar como indexación y particionamiento. Obviamente, el hardware correcto también es importante.

No hay suficiente información aquí para dar consejos específicos. Considere contratar a alguien si siente que necesita ayuda con el diseño detallado y la implementación.

• Asegúrese de que su diseño haga posible que sus insertos estén siempre al final de la tabla. Indice Índice agrupado.

• Solo tenga muy pocos índices no agrupados que respalden los informes que necesita hacer para mantenerlos al mínimo. ¿Son estos informes pregenerados? en caso afirmativo, considere esta pregunta: ¿está bien si el informe tarda 2 horas en generarse? (sin índice) o 1 minuto (con índice). ¿Quizás está bien dejar que el informe tarde 2 horas en tener un índice menos? ¿o tal vez no? Si el informe no se genera correctamente, esa es otra pregunta, ya que a los usuarios no les gusta esperar y es posible que deba implementar más índices para respaldar sus informes.

• Por cómo describe esta base de datos, parece que espera muchas filas y los datos se agregarán y crecerán mucho. ¿Consideró cómo hacer una copia de seguridad de este sistema? ¿Significo que la mayoría de los datos serán iguales y solo agregarán nuevos? No conozco los requisitos empresariales de este sistema, pero para mí parece que en un año o dos podría ser una base de datos de tamaño considerable y podría tener problemas para realizar muchas copias de seguridad completas. Considere hacer una copia de seguridad completa con registros periódicos (¿semanales?) Y diferenciales (¿diarios?) Y de transacciones (por hora?). Por supuesto, como dije, no conozco los requisitos del negocio, ¿tal vez no necesita todas las copias de seguridad todo el tiempo? El tamaño puede ser un problema en los sistemas de archivo.