¿Demasiados campos en MySQL?

Question

Desarrollé un sitio de estadísticas para un juego como un proyecto de aprendizaje hace unos años. Todavía se usa hoy y me gustaría limpiarlo un poco.

La base de datos es un área que necesita mejoras. Tengo una tabla para las estadísticas del juego, que tiene GameID, PlayerID, Kills, Deaths, DamageDealt, DamageTaken, etc. En total, hay aproximadamente 50 campos en esa tabla única y muchos más que podrían agregarse en el futuro. ¿En qué punto hay demasiados campos? Actualmente tiene 57,341 filas y es 153,6 MiB por sí mismo.

También tengo algunos campos que almacenan matrices en un BLOB en esta misma tabla. Un ejemplo de la matriz son los emparejamientos jugador contra jugador. La matriz almacena cuántas veces ese jugador mató a otro jugador en el juego. Estos son los campos más grandes en tamaño de archivo. ¿Se recomienda almacenar una matriz en un BLOB?

La matriz se parece a:

 [Killed] => Array 
      (
       [SomeDude] => 13 
       [GameGuy] => 10 
       [AnotherPlayer] => 8 
       [YetAnother] => 7 
       [BestPlayer] => 3 
       [APlayer] => 9 
       [WorstPlayer] => 2 
      ) 

Estos tienden a no exceder más de 10 jugadores.

Answer 1

Prefiero no tener una tabla con un número indeterminado de columnas (con más por venir) sino tener una tabla asociada de etiquetas y valores, para que cada usuario tenga una identificación y la use como clave en la tabla de etiquetas y valores. De esta forma solo almacenas los datos que necesitas por usuario. Creo que este enfoque se llama EAV (según el comentario de Triztian) y es cómo se guardan las bases de datos médicas, ya que hay muchos campos potenciales para un paciente individual, incluso cuando un paciente dado solo tiene un número muy pequeño de esos campos con datos reales .

es así, usted tendría

user: 
id | username | some_other_required_field 

user_data: 
id | user_id | label | value 

Ahora usted puede tener tantas o tan pocas filas user_data como sea necesario por usuario.

[Editar]

En cuanto a la matriz, yo trataría esto con una tabla relacional también. Algo como:

player_interraction: 
id | player_id | player_id | interraction_type 

Aquí podría almacenar los dos jugadores que tuvieron una interacción y qué tipo de interacción era.

Answer 2

El diseño de la mesa parece bastante bueno. Siempre que las columnas que está almacenando no se puedan calcular a partir de las otras columnas dentro de la misma fila. IE, no estás almacenando SelfKills, OtherDeath y TotalDeaths (donde TotalDeaths = SelfKills + OtherDeath). Eso no tendría sentido y podría ser cortado de tu mesa.

Me gustaría saber más sobre cómo está almacenando esas matrices en un BLOB. ¿Para qué sirven en un BLOB? ¿Por qué no están normalizados en una tabla para una transformación y análisis de datos fácil? (O están y están siendo almacenados como una matriz aquí para facilitar la visualización de los datos a los usuarios finales).

Además, me gustaría saber cuántos datos ocupan los BLOB frente al resto de la tabla. En términos generales, el tamaño de las filas no es tan grande como el número de filas, y ~ 60K no es gran cosa. Siempre y cuando no esté escribiendo consultas que necesiten verificar el valor de cada columna (lo ideal sería ignorar blobs al intentar escribir una cláusula where).

Answer 3

Con mysql tiene un límite estricto de aproximadamente 4000 columnas (campos) y 65Kb de almacenamiento total por fila. Si necesita almacenar cadenas grandes, use un campo de texto, están almacenadas en el disco. Blobs realmente debería reservarse para datos no textuales (si es necesario).

No se preocupe en general por el tamaño de su base de datos, pero piense en la estructura y en cómo está organizada e indexada. He visto correr pequeños DB como mierda.

Si aún desea números, cuando el total de bases de datos se encuentra en el rango de GB o más de cientos de miles de filas en una sola tabla, comience a preocuparse más por las cosas: 150M en 60K filas no es mucho y los escaneos de tabla no le costarán mucho en rendimiento. Sin embargo, ahora es el momento de asegurarse de crear buenos índices de cobertura en sus consultas muy utilizadas.

Answer 4

No hay nada de malo en agregar columnas a una tabla de base de datos a medida que pasa el tiempo. Los diseños de la base de datos cambian todo el tiempo. Lo que hay que tener en cuenta es cómo se agrupan los datos. Siempre he tratado una tabla de base de datos como una colección de elementos similares.

cosas que considero son los siguientes:

Al insertar datos en una fila el número de columnas será nulo?
¿Se aplica esta nueva columna al 80% de mis datos que ya están allí?
¿Estaré haciendo varias actualizaciones en algunas columnas en esta tabla?
En caso afirmativo, ¿necesito realizar un seguimiento de los valores previos por si acaso?

Al pensar en usted datos como este, puede descubrir que necesita dividir su tabla en un puñado de tablas más pequeñas separadas por claves externas.