¿Dónde se deben poner índices en una tabla de dimensiones de tiempo?

Después de leer las preguntas y respuestas de este sitio web sobre índices, me vino a la mente una pregunta.

¿Qué pasa si uno está usando una tabla de dimensiones de tiempo con el nivel más bajo de granularidad siendo el día? ¿Dónde se deben poner los índices?

Randy Melder en la pregunta: ¿Qué significa "índice" en RDBMS? dijo :

Piense en un índice como "tabla de contenido" ... que es una lista ordenada de punteros a posiciones en un archivo, también conocido como compensaciones

En el caso de la dimensión de tiempo, la mayoría de la investigación de datos se puede realizar para un día específico, una semana específica, un mes específico o un trimestre específico si la tabla de tiempo almacena todo el día para un año único .

Mi pregunta es: ¿se deben poner índices para todos esos campos?

Se supone que Day es único, así que para este entiendo perfectamente el uso de índices. Pero una identificación de la semana tendrá 7 ocurrencias , una identificación del mes tendrá 30/31 ocurrencias , una identificación del trimestre tendrá más o menos 120 ocurrencias .

• ¿Debería uno poner índices para esos campos?
• ¿Seguirá siendo útil?

Te pregunto eso porque en la misma pregunta, David Spillett dijo:

Por supuesto, agregar demasiados índices puede ser una mala optimización, ya que el espacio adicional utilizado para almacenar los índices (y la carga de E / S para mantenerlos si su DB ve muchas operaciones de escritura) puede ser un problema peor que las consultas de lectura ligeramente menos óptimas , así que no lo hagas en exceso.

Entonces, ¿cuáles serían las mejores consideraciones para el caso de la dimensión temporal?

Es probable que no se encuentre con los problemas de escritura, ya que supongo que esto se crearía una vez (o una vez al año) y luego no se tocaría.

Pero usar un índice probablemente será un obstáculo si está buscando por semana ... El problema es que, si se usa el índice, podría escanear eso primero y luego tomar cada registro de la tabla individualmente, lo que cuando usted ' Si extrae más del 5-20% de los registros, generalmente es más rápido hacer un escaneo completo de la tabla y luego descartar los registros que no le interesan.

No conozco ningún RDBMS importante que no se optimice para esto cuando se trata de datos bien distribuidos. Si no está bien distribuido (p. Ej., Uno de los valores en una columna aparece el 95% del tiempo, pero también hay otros valores posibles), es posible que deba calcular histogramas en la tabla y no utilizar un marcador de posición para el valor al buscar, para que el optimizador de consultas tenga el valor que se busca al generar el plan de ejecución.

Probablemente no indexaría el día de la semana. Verificaría la documentación de mi base de datos para ver cuál es su compensación para las lecturas indexadas frente a los escaneos de tabla completa para ver si indexaría el día del mes o el mes del año. Probablemente indexaría DOY / día del año si estuviera presente (de todos modos, parece que es su índice único)

Un índice no tiene que ser único para ser útil, por lo que la respuesta es que depende . Si sus consultas se benefician de la presencia del índice, entonces pueden ser una adición valiosa. No sé si debería haber pautas especiales con respecto a las columnas de tiempo. Trátelos como cualquier otra columna e indícelos según la utilidad de las consultas.

La regla general es que cuanto más selectivo es el índice (la selectividad se define como el número de valores únicos en una columna dividida por el número de filas en la tabla), más probable es que el motor use el índice si se realiza una consulta usa la columna en una cláusula where.

Si está considerando indexar una columna, ejecutar una consulta seleccionando en la columna indexada antes y después y mirando los planes de ejecución le dirá si se está utilizando el índice y, de ser así, cuánto está ayudando el índice. Idealmente, la consulta que usa para la prueba es la que usaría su aplicación.

Hasta ahora, mi regla general ha sido no poner ningún índice en mis bases de datos de desarrollo mientras estoy trabajando en ellos. A medida que la base de datos de producción se hace más grande, utilizo el registro de la base de datos y EXPLAINpara averiguar qué necesita indexación, y luego creo solo los índices necesarios. Esto funciona bien siempre que el uso de la base de datos aumente gradualmente y mantenga bajos los recuentos de índices.

Al analizar los datos en la base de datos, generalmente necesito agregar índices adicionales para acelerar las solicitudes que no son comunes en la producción. Siempre hago esto en copias de la base de datos de producción, por lo que estos índices nunca se agregan a la producción.