¿Cómo almacenar múltiples opciones en una sola tabla?

Resuelto Nelson Oko-oza asked hace 9 años • 0 respuestas

Quiero diseñar una aplicación para el cálculo de resultados.

Primero, necesito saber cómo almacenar registros en una base de datos MySQL de tal manera que los estudiantes puedan tener tantos cursos adjuntos, por ejemplo, el estudiante A puede tener 6 materias adjuntas, mientras que el estudiante B puede tener 12 materias adjuntas. .

En este caso, necesito saber cómo podría diseñar una estructura de base de datos que permita que un campo almacene tantos temas como sea posible en forma de matriz .

Cualquier sugerencia o una mejor manera de manejar esto será muy apreciada.

Nelson Oko-oza avatar Sep 17 '15 05:09 Nelson Oko-oza
Aceptado

Lea sobre normalización de datos , conceptos generales de indexación y restricciones de clave externa para mantener los datos limpios con integridad referencial. Esto te pondrá en marcha.

El almacenamiento de datos en matrices puede parecerle natural en el papel, pero para el motor de base de datos, el rendimiento en su mayoría no requiere uso de índice. Además, el día 2 descubrirá que acceder y mantener sus datos será una pesadilla.

Lo siguiente debería ayudarle a empezar con buen pie mientras juega. Se une también.

create table student
(   studentId int auto_increment primary key,
    fullName varchar(100) not null
    -- etc
);

create table dept
(   deptId int auto_increment primary key,
    deptName varchar(100) not null -- Economics
    -- etc
);

create table course
(   courseId int auto_increment primary key,
    deptId int not null,
    courseName varchar(100) not null,
    -- etc
    CONSTRAINT fk_crs_dept FOREIGN KEY (deptId) REFERENCES dept(deptId)
);

create table SCJunction
(   -- Student/Course Junction table (a.k.a Student is taking the course)
    -- also holds the attendance and grade
    id int auto_increment primary key,
    studentId int not null,
    courseId int not null,
    term int not null, -- term (I am using 100 in below examples for this term)
    attendance int not null, -- whatever you want, 100=always there, 0=he must have been partying,
    grade int not null, -- just an idea   
    -- See (Note Composite Index) at bottom concerning next two lines.
    unique key(studentId,courseId,term), -- no duplicates allowed for the combo (note student can re-take it next term)
    key (courseId,studentId),
    CONSTRAINT fk_sc_student FOREIGN KEY (studentId) REFERENCES student(studentId),
    CONSTRAINT fk_sc_courses FOREIGN KEY (courseId) REFERENCES course(courseId)
);

Crear datos de prueba

insert student(fullName) values ('Henry Carthage'),('Kim Billings'),('Shy Guy'); -- id's 1,2,3
insert student(fullName) values ('Shy Guy');

insert dept(deptName) values ('History'),('Math'),('English'); -- id's 1,2,3

insert course(deptId,courseName) values (1,'Early Roman Empire'),(1,'Italian Nation States'); -- id's 1 and 2 (History dept)
insert course(deptId,courseName) values (2,'Calculus 1'),(2,'Linear Algebra A'); -- id's 3 and 4 (Math dept)
insert course(deptId,courseName) values (3,'World of Chaucer'); -- id 5 (English dept)

-- show why FK constraints are important based on data at the moment
insert course(deptId,courseName) values (66,'Fly Fishing 101'); -- will generate error 1452. That dept 66 does not exist
-- That error is a good error to have. Better than faulty data

-- Have Kim (studentId=2) enrolled in a few courses
insert SCJunction(studentId,courseId,term,attendance,grade) values (2,1,100,-1,-1); -- Early Roman Empire, term 100 (made up), unknown attendance/grade
insert SCJunction(studentId,courseId,term,attendance,grade) values (2,4,100,-1,-1); -- Linear Algebra A
insert SCJunction(studentId,courseId,term,attendance,grade) values (2,5,100,-1,-1); -- World of Chaucer

-- Have Shy Guy (studentId=3) enrolled in one course only. He is shy
insert SCJunction(studentId,courseId,term,attendance,grade) values (3,5,100,-1,-1); -- Early Roman Empire, term 100 (made up), unknow attendance/grade
-- note if you run that line again, the Error 1062 Duplicate entry happens. Can't take same course more than once per term

Algunas preguntas sencillas.

¿Qué curso hay en qué departamento?

mostrar todo, utiliza alias de tabla (abreviaturas) para escribir menos y mejorar la legibilidad (a veces)

select c.courseId,c.courseName,d.deptId,d.deptName
from course c
join dept d
on c.deptId=d.deptId
order by d.deptName,c.courseName -- note the order
+----------+-----------------------+--------+----------+
| courseId | courseName            | deptId | deptName |
+----------+-----------------------+--------+----------+
|        5 | World of Chaucer      |      3 | English  |
|        1 | Early Roman Empire    |      1 | History  |
|        2 | Italian Nation States |      1 | History  |
|        3 | Calculus 1            |      2 | Math     |
|        4 | Linear Algebra A      |      2 | Math     |
+----------+-----------------------+--------+----------+

¿Quién tomará el curso El Mundo de Chaucer este trimestre?

(conociendo el CourseId=5)

Lo siguiente se beneficia de uno de nuestros índices compuestos en SCJunction. Un compuesto es un índice en más de una columna.

select s.StudentId,s.FullName
from SCJunction j
join student s
on j.studentId=s.studentId
where j.courseId=5 and j.term=100
+-----------+--------------+
| StudentId | FullName     |
+-----------+--------------+
|         2 | Kim Billings |
|         3 | Shy Guy      |
+-----------+--------------+

¿Kim Billings está inscrita en qué este trimestre?

select s.StudentId,s.FullName,c.courseId,c.courseName
from SCJunction j
join student s
on j.studentId=s.studentId
join course c
on j.courseId=c.courseId
where s.studentId=2 and j.term=100
order by c.courseId DESC -- descending, just for the fun of it
+-----------+--------------+----------+--------------------+
| StudentId | FullName     | courseId | courseName         |
+-----------+--------------+----------+--------------------+
|         2 | Kim Billings |        5 | World of Chaucer   |
|         2 | Kim Billings |        4 | Linear Algebra A   |
|         2 | Kim Billings |        1 | Early Roman Empire |
+-----------+--------------+----------+--------------------+

Kim está abrumada, así que deja la clase de matemáticas.

delete from SCJunction
where studentId=2 and courseId=4 and term=100

Ejecute la declaración de selección anterior que muestra lo que está tomando Kim:

+-----------+--------------+----------+--------------------+
| StudentId | FullName     | courseId | courseName         |
+-----------+--------------+----------+--------------------+
|         2 | Kim Billings |        5 | World of Chaucer   |
|         2 | Kim Billings |        1 | Early Roman Empire |
+-----------+--------------+----------+--------------------+

Ah, término mucho más fácil. Aunque papá no estará feliz.

Tenga en cuenta cosas como SCJunction.term. Se puede escribir mucho sobre eso, lo pasaré por alto por el momento, aparte de decir que también debería estar en algún FK en alguna parte. Es posible que desee que su término se parezca más a SPRING2015 y no a un int.

Y en lo que respecta a la identificación. Esta es la forma en que yo lo haría. Es una preferencia personal. Sería necesario conocer los números de identificación y buscarlos. Otros podrían optar por tener un ID de curso similar a HIST101 y no 17. Son mucho más legibles (pero más lentos en el índice (apenas). Así que haga lo que sea mejor para usted.

Índice compuesto de notas

Un índice compuesto (ÍNDICE significa CLAVE y viceversa) es aquel que combina varias columnas para una recuperación rápida de datos. Los pedidos se invierten para los dos compuestos en la tabla SCJunction de modo que, dependiendo del universo de consultas que buscan sus datos, el motor de base de datos puede elegir qué índice usar para una recuperación más rápida según la columna más a la izquierda que busca. .

En cuanto a la clave única, n.° 1, el comentario al lado que indica que no se deben aplicar duplicados (es decir, datos basura) se explica por sí mismo. Por ejemplo, estudiante 1 curso 1 período 1 no puede existir dos veces en esa tabla.

Un concepto crucial que hay que comprender es el concepto de left-mostordenación de los nombres de las columnas en un índice.

Para consultas que van studentId solo después de , se utiliza la clave que aparece studentIdprimero ( ). left-mostEn las consultas que van courseId solo después de , se utiliza la clave que está courseIdmás a la izquierda. En consultas que van después de StudentId y CourseId, el motor de base de datos puede decidir qué clave compuesta usar.

Cuando digo "ir tras", me refiero a la condición on clauseo where clause.

Si uno no tuviera esas dos claves compuestas (con las columnas 1 y 2 invertidas), en las consultas donde la columna buscada no está indexada left-most, no se beneficiaría con el uso de claves y sufriría una exploración de tabla lenta para que los datos regresen.

Entonces, esos dos índices combinan los siguientes 2 conceptos

  • Recuperación rápida de datos basada en el extremo izquierdo o en ambos (columnas StudentId y CourseId)
  • Hacer cumplir la no duplicación de datos en esa tabla según los valores de StudentId, CourseId y Term

La comida para llevar

La conclusión importante es que las tablas de Junction permiten una recuperación rápida del índice y una gestión sensata de los datos frente a los datos delimitados por comas (mentalidad de matriz) agrupados en una columna, y toda la miseria de utilizar una construcción de este tipo.

Drew avatar Sep 16 '2015 23:09 Drew

Para completar, no en el sentido de que esta sea una solución recomendada general:

MySQL a partir de la versión 5.7.8 proporciona el tipo de datos JSON , que permite almacenar y recuperar objetos y matrices en formato JSON .

De esta manera, puede almacenar objetos y matrices completos en un campo, como se vería una matriz:

 ['subject_1', 'subject_2', 'subject_3']

Especialmente los principiantes no lo saben y reinventan la rueda mediante otra implementación de cadenas separadas por comas o utilizando enfoques de serialización/deserialización dependientes del lenguaje.

Al menos JSON se usa con mucha frecuencia y se analiza fácilmente como formato de intercambio de datos.

Hay casos de uso válidos para almacenar matrices y objetos dentro de un campo MySQL, por ejemplo, para optimizar la velocidad o cuando tiene propiedades dinámicas o desconocidas que aún desea guardar en una base de datos.

Sin embargo, como regla general, si confía en almacenar objetos y matrices en MySQL, lo más probable es que el diseño de su base de datos no funcione o debería utilizar una base de datos basada en documentos como MongoDB .

k0pernikus avatar Sep 17 '2015 19:09 k0pernikus