¿Una clave principal de 5 columnas es mala para una tabla grande (más de 100 millones)?

Estaba leyendo sobre algunos problemas de DB de la vida real, y un proyecto tenía una tabla de más de 100 millones de filas que tenía 5 columnas como principal. Estoy pensando que esto es malo, pero ¿alguien puede decirme exactamente por qué?

La tabla era una especie de tabla de micro rollup / agregación, por lo que las 5 columnas eran como (day, market_id, product_id ...). Al principio pensé que una clave primaria de 5 columnas no era ideal, pero cuanto más pensaba, realmente no podía encontrar una buena razón por la cual era mala.

Esto fue en una discusión nocturna con la mitad de los ingenieros de la compañía. Alguien acaba de mencionar que este era un mal diseño, un ingeniero senior estuvo de acuerdo, pero nadie realmente dijo por qué. ¡Intento investigar el asunto por mí mismo!

Hay problemas de rendimiento con claves primarias muy complejas. Y puede que no se defienda contra la duplicación tan bien como lo haría una clave primaria más simple.

Sin embargo, hay un patrón de diseño que con frecuencia produce tablas con una clave primaria compuesta de seis o más componentes. Son tablas de hechos del esquema estelar. Si la tabla de hechos de un esquema en estrella tiene seis dimensiones, la clave primaria tendrá seis componentes. Nunca he visto una tabla de hechos sin clave primaria declarada, y creo que vale la pena la sobrecarga, a pesar de que el proceso ETL todavía tiene que escribirse con bastante cuidado.

Algunas bases de datos de informes imitan el patrón del esquema en estrella, incluso si no está explícitamente diseñado de esa manera.

Más de 100 millones de filas no son demasiado grandes para una tabla de hechos, especialmente con los grandes datos actuales.

La tabla en cuestión era una tabla de acumulación / agregación.

Entonces no solo está bien, es "correcto".

Y huele a una tabla Resumen, ya que comienza con day.

¿Tienes algunos índices secundarios? Tenga en cuenta que si está utilizando InnoDB, el resto de las columnas PRIMARY KEY se agregarán al final del índice secundario. Nuevamente, esto no es necesariamente un problema.

100 millones de filas es mucho para un paquete acumulativo. Parece que la mesa es demasiado fina. Es decir, tal vez si (fecha, a, b, c, d) debería tener 4 acumulaciones con PK como (fecha, a, b, c), (fecha, b, c, d), (fecha, c, d, a), (fecha, d, a, b) (o algunas combinaciones adecuadas). Al hacer eso, cada uno puede tener solo 10 millones de filas, lo que hace que los informes sean aún más rápidos, al tiempo que tiene casi tanta flexibilidad en el informe.

O tal vez cambie a (semana, a, b, c, d), lo que lleva a tal vez solo 14 millones de filas. (Probablemente más)

Uso de PARTITION para facilitar la poda --- Ingestión de alta velocidad --- Consejos de Data Warehouse --- Tablas de resumen . Estos resumen muchas de las técnicas que he desarrollado en varios proyectos de DW. Como se puede deducir, cada proyecto es diferente. El número 'típico' de tablas de resumen (en mi experiencia) es 3-7. El objetivo en el resumen es 10 filas de hechos -> 1 fila de resumen. (Eso puede ser una 'mediana'). En un caso raro, resumí una tabla de resumen. En otro caso raro, particioné una tabla de resumen con buenos resultados; por lo general, las tablas de resumen son lo suficientemente pequeñas como para que sean lo suficientemente rápidas para el acceso directo desde una interfaz de usuario.

Bueno, en realidad tener un PK con más de 5 columnas no es necesariamente malo en sí mismo.

Se vuelve malo una vez que el PK también es el índice agrupado, ya que ese contaría como el identificador de fila y, por lo tanto, se agregaría a cada fila en un índice NC. Esto aumentaría drásticamente el espacio requerido.

También sería malo una vez que realmente use el PK por otro FK, ya que debe tener los datos de las más de 5 columnas tanto en la tabla actual como en la que hace referencia. ¡Una vez más aumentará mucho el almacenamiento!

En cuanto al rendimiento, será malo una vez que la PK se haya utilizado como índice, déjelo solo dentro de la tabla o junto con un FK, ya que una PK-Key más grande que contenga más de 5 columnas ocupará más espacio, por lo tanto, menos entradas cabe dentro de una página y, en adelante, es necesario leer más páginas para analizar el índice.

Dicho esto, siempre puede haber una buena razón para hacerlo de todos modos, como, por ejemplo, una tabla de hechos. Por lo tanto, la mejor respuesta sería en la mayoría de los casos: ¡depende!

Saludos Dennis

Durante más de 15 años no necesité esa clave, la vi a veces y solo estaba causando problemas. Muchos problemas En primer lugar, la clave principal es para mantener la integridad de los datos, y deben ser sintéticos. No deberían tener ningún vínculo con el mundo real. Por qué ? Una vez que el mundo real cambie, y con seguridad, su clave principal desaparecerá y tendrá que actualizarla y toda la información relacionada.

Imagine que necesita recordar este ker en alguna otra tabla / base de datos / servicio en lugar de un campo, necesita copiar varios, y puede olvidar copiar algunos de ellos. En cambio, la clave primaria sistémica es solo una pieza de datos que debe proporcionar. No estoy mencionando la unicidad del índice, que puede ser otro gran tema de discusión.

Por lo tanto, un resumen breve, la clave primaria sintética (incremento automático, guid, ...) es fácil de mantener, copiar, ...

Por lo tanto, considero una clave primaria sintética y otra clave para las 5 columnas que mencionó.

Por último, si la tabla es solo agregada, y nunca alguien necesitará hacer referencia a la fila por teclas (pero el mundo cambia, confía en mí, al menos para mí cambia permanentemente), probablemente lo dejaré como está (primaria tecla con cinco filas), pero en caso de que solía tener, siempre causa muchos problemas. Entonces te lo dije.