mysql ¿demasiadas columnas?

Question

Estoy creando una tabla con 30-50 columnas. Hay aproximadamente 200K de estas filas. ¿Se recomienda almacenar esta información en tablas separadas? ¿Hay problemas de rendimiento cuando tienes tantas columnas?

Explicaré un poco sobre la mesa. Tengo que almacenar todos los juegos de deportes en los últimos 10 años (baloncesto, béisbol, fútbol, ​​hockey). Para cada uno de estos, necesito guardar datos adicionales. Algunos de estos datos me permiten reutilizar campos en todos los deportes. Por ejemplo, cada equipo tiene un equipo local y visitante y una fecha de evento.

Sin embargo, para cada uno de estos juegos también estoy almacenando cosas como cuántos first-downs se lograron, cuántos ponches y tres punteros. Obviamente, estos datos solo se relacionan con algunas de las filas en la tabla. Termino teniendo muchos campos NULL en cada fila como resultado.

Puedo dar más detalles si es necesario. Gracias de antemano por cualquier consejo general.

Answer 1

Para más detalles sobre la respuesta RichardOD 's, se En general, tiene tres opciones cuando se trata de subtipar, y el que elija depende de lo que necesite hacer con los datos en cuestión.

La primera opción es la que está utilizando actualmente: mantener todas las columnas relacionadas con los diferentes tipos en una tabla, con indicadores y nulos utilizados para indicar qué tipo es un registro determinado. Es la forma más sencilla de administrar la subtipificación, y generalmente funciona bien cuando solo tiene algunos tipos o si los diferentes tipos no son muy diferentes. En tu caso, parece que los tipos pueden variar bastante.

La segunda opción es mantener una tabla central que contenga todas las columnas comunes entre los subtipos, y tener relaciones de uno a uno con otras tablas que contengan los detalles específicos del tipo de esos tipos.

La tercera opción es no pensar en los diferentes tipos como subtipos en absoluto y simplemente mantener todos los tipos de registros en tablas separadas. Por lo tanto, no tendría una tabla común entre los tipos que conserva los datos comunes, y cada tabla tendría algunas columnas que se repiten en las tablas.

Ahora, cada opción tiene su lugar. Utilizarías la primera opción cuando no hay muchas diferencias entre los diferentes tipos. Utilizaría la segunda opción si necesita manipular los campos comunes independientemente de los campos específicos del tipo; por ejemplo, si desea enumerar todos los juegos de deportes en una grilla grande con información general, y luego permitir que los usuarios hagan clic para ver los detalles específicos del tipo de ese juego. Utilizarías la tercera opción cuando los tipos no están realmente muy relacionados y solo los estás almacenando juntos por conveniencia; esquemas diferentes, incluso si comparte algunos campos, no deberían fusionarse.

Así que piense qué necesita hacer con los datos y cómo encaja en las tres opciones y decida por usted mismo qué es lo mejor. Si no puede decidir, actualice su pregunta con los detalles sobre cómo planea usar los datos y yo o alguien más debería poder ayudarlo más.

Answer 2

Creo que el problema es que tiene un model like this (el enfoque de almacenar todo en una sola mesa). This approach y también this approach son dos de las alternativas que puede elegir, estoy seguro de que otros tendrían algunas sugerencias más.

Todos tienen sus pros y sus contras. No puedo comentar sobre las características de rendimiento de ellos en MySql, pero ciertamente los otros enfoques reducen el uso de nulos, lo cual solo puede ser algo bueno.

Si está realmente interesado en las diferencias entre los 3 enfoques, recomendaría comprar el libro de Martin Fowler's Patterns of Enterprise Application Architecture.

En cuanto a las características de rendimiento, es posible que desee consultar las preguntas like this one y also this one.

Puede leer acerca de vertical partitioning in MySql here.

Answer 3

Definitivamente miraría normalizing the table. Si bien no estoy seguro acerca de los beneficios de rendimiento, lo más probable es que haya un beneficio de almacenamiento con una gran cantidad de entradas.

Mi primer cambio sería tener todos los datos que se relaciona con sólo 1 o 2 deportes y tenerlos en tablas separadas con una clave externa de la tabla principal

Answer 4

Sí, use muchas columnas si tiene sentido. Siempre que no esté usando un antipatrón como "campo1, campo2, campo3", etc., está bien.

Lotes de NULL es bueno, no duelen demasiado. También 200k es una cantidad tan pequeña de filas que es poco probable que veas muchos problemas de rendimiento. No sé cuántas inserciones tiene previsto hacer en esta tabla, pero si es < 100 por segundo, no veo que haya ningún problema.

Querrá indexarlo de alguna manera. El número de índices afectará el rendimiento de inserción, pero imagino que la mayoría de sus columnas no necesitarán ser indexadas.

Con una mesa tan pequeña realmente no importa demasiado, nada de eso. Puede duplicar sus datos una y otra vez sin tener problemas de espacio: se encuentra en una posición privilegiada.

Answer 5

200K por 50 valores no es una gran tabla. No se preocupe por el rendimiento hasta que tenga bajo control las cosas tales como la facilidad de uso y la libertad de la auto-contradicción.

Hay una variedad de razones para descomponer una tabla. Descomponer una tabla significa dividirla en dos o más tablas con la mayoría de las columnas dirigidas a una sola tabla, y otras columnas que entran a más de una tabla (claves externas).

Farell mencionó la mormalización. El principal beneficio de la normalización es que excluye ciertos tipos de anomalías de actualización, incluidas aquellas que permiten almacenar hechos contradictorios en la misma tabla. Los beneficios de almacenamiento son secundarios. Los beneficios de rendimiento, si están presentes, probablemente sean menores. Una vez dicho esto, la normalización es lo más importante que puede aprender sobre el diseño de la mesa. Si violas las reglas de normalización sin entender las consecuencias, estás volando a ciegas.

Si me presentaron una tabla de base de datos con 40 columnas o más y había algún tipo de problema en el databse (rendimiento, corrupción, o lo que sea), buscaría si esa tabla se puede normalizar aún más, y ¿Cuáles son los costos/beneficios de hacerlo?

Hay una variedad de razones para dividir una tabla. Como dijo Reinerpost, no empieces a preocuparte por las partidas hasta que tengas la normalización bajo control.