Quiero proponer un caso

[replica]

A ver qué solución es la óptima (o si me dan alguna mejor).

Imaginemos un centro de estudios (sea una universidad, un instituto o una academia privada). Un colegio no me vale, ya que las clases no son tan flexibles, aunque el caso se podría adoptar perfectamente para una escuela primaria.

Tenemos, por un lado, la tabla de alumnos. Con la ID del alumno, nombre, apellidos...
Por otro lado, la de profesores. Id del profesor, nombre, apellidos...

Vamos a confeccionar la relación entre ellos, y le llamaremos HORARIOS. Aquí me vienen 2 soluciones:

La primera: en esta tabla, tendremos la fecha en la que se imparte la clase y su horario, la id del profesor, la id de cada uno de los 30 alumnos como máximo, y si asisten o no. Al final, como mucho, unos 60 y pico campos. Lo único que tengo que comprobar, al hacer la programación, es que un alumno no se repita dentro de la misma fila. La programación de esto creo que resulta sencilla. El problema que veo es que el diseño de la tabla tiene 30 claves foráneas referenciando a la misma tabla, una por cada alumno. Esto me alarma, ya que el diseño se sale de lo estándar.

La segunda solución, más estandar, es dividir la tabla horarios en dos:
Una tabla en la que almacenaría el profesor, la fecha y la hora, y le asigno un id.
Y otra tabla en la que tendría el id de la tabla anterior, un identificador de alumno y un campo para saber si asiste o no.

El segundo caso es mucho más estándar, pero es un poco más difícil de programar (a mi parecer).

Me gustaría saber qué opción utilizaríais vosotros, cuál obtendría mayor rendimiento y bueno, simplemente debatir un poquito sobre el caso.

Un saludo.

[leonardo_josue]

Hola Replica:

En realidad en esto del modelado de datos no hay una "mejor" manera de hacer las cosas, aunque sí hay que tomar en cuenta algunas consideraciones:

Por ejemplo, en el primer caso, estás considerando 30 alumnos como máximo, pero qué pasa si fuera el caso de que no completaras el grupo??? imagina que alguna clases será tomada sólo por 20 alumnos... ¿cómo vas a manejar los campos restantes? si tu idea es poner los id's a tu tabla alumnos, entonces estás forzando a que todos los grupos sean de 30 alumnos, no menos... y si piensas en la posibilidad de poner campos NULL, entonces no podrías definir las relaciones de FK, y una tabla sin relaciones de integridad, se convierte en simplemente en un montón de basura.

El segundo modelo es un poco más flexible, aunque no veo la necesidad de el campo para saber si está escrito o no... es decir, por un lado tienes la tabla de alumnos, por otro lado la tabla de maestros y finalmente la tabla de horarios-maestro... ahora bien, la cuarta tabla lo único que debería de incluir es el id del alumno y el id de de la tabla horarios-maestros... si un alumno NO VA A TOMAR CIERTA CLASE, entonces simplemente NO APARECE EN ESTA TABLA. es decir, en la cuarta tabla sólo aparecerían las clases que toman cada alumno... para evitar que un alumno esté "repetido" en una misma clase, simplemente defines una llave compuesta... (es la misma validación de la que hablabas en el primer caso)

Hay mucha tela de donde cortar, pero en definitiva, creo que el primer modelo más que facilitarte las cosas, terminaría por complicarlas.

Saludos
Leo.

[replica]

Iniciado por leonardo_josue

Hola Replica:

En realidad en esto del modelado de datos no hay una "mejor" manera de hacer las cosas, aunque sí hay que tomar en cuenta algunas consideraciones:

Por ejemplo, en el primer caso, estás considerando 30 alumnos como máximo, pero qué pasa si fuera el caso de que no completaras el grupo??? imagina que alguna clases será tomada sólo por 20 alumnos... ¿cómo vas a manejar los campos restantes? si tu idea es poner los id's a tu tabla alumnos, entonces estás forzando a que todos los grupos sean de 30 alumnos, no menos... y si piensas en la posibilidad de poner campos NULL, entonces no podrías definir las relaciones de FK, y una tabla sin relaciones de integridad, se convierte en simplemente en un montón de basura.

Sí, en el primer caso pensé en poner campos nulos. En realidad, (creo) que no pasaría nada, si está nulo es que no hay alumnos y punto, no hay ninguna tabla de donde sacar los datos de ese alumno, porque no hay. Y esta tabla de horarios no iba a prestar su clave a ninguna otra tabla, así que mi pensamiento es que se puede sostener sin problema (no llegué a ponerla en producción). Estudiando el caso con un poco más detenimiento, llegué a la conclusión de que no era el caso correcto, y derivé en el segundo.

El segundo modelo es un poco más flexible, aunque no veo la necesidad de el campo para saber si está escrito o no... es decir, por un lado tienes la tabla de alumnos, por otro lado la tabla de maestros y finalmente la tabla de horarios-maestro... ahora bien, la cuarta tabla lo único que debería de incluir es el id del alumno y el id de de la tabla horarios-maestros... si un alumno NO VA A TOMAR CIERTA CLASE, entonces simplemente NO APARECE EN ESTA TABLA. es decir, en la cuarta tabla sólo aparecerían las clases que toman cada alumno... para evitar que un alumno esté "repetido" en una misma clase, simplemente defines una llave compuesta... (es la misma validación de la que hablabas en el primer caso)

Hay mucha tela de donde cortar, pero en definitiva, creo que el primer modelo más que facilitarte las cosas, terminaría por complicarlas.

Saludos
Leo.

Sí tengo la necesidad de saber si acude o no, porque el alumno está inscrito en esa clase, y es en esa tabla donde guardo la información de que pertenece a esa hora, ese día y con ese profesor.

El caso es tan flexible que el alumno es capaz de pedir que le cambien la hora a otro día y con otro profesor, y necesito saber si ha tomado clases o no, y cuántas.

La clave principal de esa segunda tabla, obviamente, es compuesta (Id de horario + Id de alumno).