¿Qué debo usar? ¿Una cadena o 15 campos enteros?


9

Estoy desarrollando un programa de seguimiento de estudiantes donde necesito almacenar 15 marcas de examen.

Puedo almacenar las marcas como una cadena y dividirlas cuando sea necesario, para fines como realizar operaciones aritméticas. Sin embargo, necesito el mayor rendimiento posible.

¿Cual es mejor? ¿Un solo campo de cadena o 15 campos int individuales?


"15 marcas de examen", ¿por lo tanto, como la opción múltiple de un solo examen o las puntuaciones de 15 pruebas?
rfusca

puntajes de 15 pruebas
mike

1
Sin más información sobre el tipo de base de datos (¿tradicional relacional con indexación disponible?) Y los requisitos para el acceso a los datos y los patrones de uso, es difícil decir qué diseño debe usar y cómo funcionará.
Cade Roux

Respuestas:


27

Si ya está hablando de división y computación, no almacene esto como una matriz.

Independientemente de la teoría relacional y las reglas tradicionales de normalización y el dogma, es simplemente un diseño que le brinda una flexibilidad MÍNIMA.

Haga que cada resultado del examen sea una fila.

No estoy tratando de anticipar todo, pero hay una gran cantidad de cosas que este diseño más granular (y, sí, normalizado) y solo un poco más costoso en espacio facilita lo que puede o no necesitar ahora y puede o no Puede que no necesite en el futuro:

  • ¿Tirando el resultado más alto y más bajo? Tendrás que cortar tu matriz y ordenarla.

  • Promediando? Tendrás que cortarlo y totalizarlo

  • ¿Análisis del resultado del examen por examen entre los estudiantes? Tendrás que cortar y girar

  • ¿Ordenando para contar (o instancia GCSE británica, donde podría ser 7 As y 2Bs)? Tendrás que cortar y ordenar

Tenga en cuenta que todo este corte y clasificación viene muy barato en un diseño indexado y normalizado.


44
Justo lo que iba a decir, ¡pero lo dijiste mejor! Almacenar valores múltiples en una cadena es una de las peores opciones de diseño posibles para cualquier base de datos.
HLGEM

+1 Gran explicación adicional de la mía. Tiendo a ser demasiado conciso jajaja.
rfusca

12

Para los puntajes, en cuanto al rendimiento, el claro ganador lo está almacenando numéricamente algo así;

create table test_scores
(
  student_id int,
  test_id int,
  score int
);

Es fácil de consultar, fácil de actualizar y agregar, y súper fácil y rápido para realizar agregados. Dada la opción de "almacenar esta información como una cadena que tengo que dividir" o "almacenar en una columna" ... el ganador casi siempre será "almacenar en una columna" para la mayoría de los casos de uso en un RDBMS.


Si siempre es el mismo conjunto de 15 exámenes, podría ser que almacenarlos desnormalizados (15 columnas) sea más rápido de procesar. Una pregunta, ¿propuso a propósito un tipo de datos entero?
Edward Dortland el

Además, por cada 15 exámenes de 1 estudiante, ahora está almacenando 15 veces una identificación de estudiante y una identificación de prueba adicional.
Edward Dortland el

1
violín aquí - sqlfiddle.com/#!1/f7343/10
rfusca

66
@EdwardDortland siempre será 15 hasta que no lo sea.
allí el

1
@EdwardDortland: Los cálculos están bien. Ahora, ¿puedes hacerlos para los índices que puedas necesitar?
ypercubeᵀᴹ

1

siempre que use tiny int (0 a 255) usando un char (15) o 15 tinyint es lo mismo (tamaño). Entonces, desde una perspectiva de rendimiento, elija los 15 tinyints ya que ahorra en la extracción y el manejo de la cadena.

ACTUALIZAR

si las marcas son de dos dígitos, necesitará CHAR (30) y eso es dos veces el tamaño de 15 veces un minúsculo.


99
Dado este diseño extremadamente simple, si hay una institución en este planeta que tiene suficientes estudiantes que rinden 15 exámenes (con calificaciones) para causar problemas de rendimiento en un RDBMS moderno, lloraré hasta quedarme dormida esta noche.
Philᵀᴹ

1
Si las marcas son de dos dígitos? Pero tiny int cubre puntajes de 0 a 255, o -127 a 127 dependiendo de cómo prefiera contar. Entonces, dado que los puntajes rara vez son negativos, eso da más de 250 puntos para un examen, y la mayoría de los exámenes se califican en una escala de 0-100%. Creo que tinyint es absolutamente útil aquí.
jcolebrand

Sí, estamos de acuerdo, era simple al afirmar que con las marcas de dos dígitos opuestas a las marcas de un solo dígito, es aún peor almacenarlo como char. Desde entonces, necesitaría char (30) en lugar de char (15). Aunque sea de dos dígitos o no, 15 pequeñas entradas siempre serán solo 15 bytes.
Edward Dortland el

-1 porque esta respuesta recomienda los campos por diseño fila que es muy inferior al almacenamiento de cada resultado de examen en su propia fila tal como se propone por los demás puestos
miracle173
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.