#Discutiendo las relaciones del pana
1 messages · Page 1 of 1 (latest)
No soy explicando cosas, pero esa tabla Materias no está normalizada
tienes literalmente 2 tablas bien y las otras tres tienes un fallo de concepto
una tabla no sirve literalmente para poner como columnas los valores que quieres almacenar. En caso de la tabla profesor, almacenas su nombre, su apellido, etc
en caso de materias no puedes almacenar matematicas, tendrias que almacenar el nombre de la materia, el curso en que se imparte por ejemplo, etc
En el caso de saber exactamente cuantas asignaturas existen en tu aplicación y que NUNCA vayan a cambiar (que no creo que esto ocurra), deberías plantearte una columna por ejemplo en profesor en la que se almacena el tipo de asignatura que da (siempre y cuando el profesor solo imparta una asignatura)
creo que me he explicado bien
El problema con materias es que posiblemente está pensando que una columna es un campo único de dato, al menos como está graficado. Lo ideal (si no hay más datos) las columnas de la tabla solo sería la id/name
Este problema de materias, te pasa exactamente igual con grados y turnos
es el mismo fallo de concepto
Sí, exactamente
También, las relaciones 1:M, la referencia debería estar de lado de M
Si es postgresql usen Enum, ya sea numérico y en el back lo enumeran con el nombre de la materia o en formato string
Profesor y Alumno se puede abstraer los datos personales en otra tabla y referenciarla
en mysql puedes usar tambien enum
Eso ayuda igual a tener una tabla simple en la cual incluso se te hace más fácil buscar las personas sin importar el tipo de persona que sea
Si pero es diferente a PostgreSQL, en MySQL prefiero usar relaciones
yo es que solo usaría enum en caso de saber que van a ser datos que nunca cambiarán
Pero igual, cualquiera de los métodos que uses, lo que cambiaría es la tabla alumno profesor, si usas enum igual pasar a Enum la tabla grado y materias
si materias pueden añadirse y eliminarse comunmente, crearia la tabla aparte y relacionaba
Las materias son fijas, y podes extender el enum y en el back controlar si es válido agregar o no esa materia
En caso de que esa materia ya no sea válida para seguir agregando profesores con la misma, igual en grados
las materias pueden no ser fijas, pero en su mayoria si lo son
yo tuve dos planes de carrera distintos en la universidad
cambiaron muchas materias
Que sea fijo o no seguiría usando Enums, el concepto de Enum es un tipo el cual puede ser extendido pero no es recomendable reducirlo (eliminar tipos), pero sacando eso no deja de ser eso: Un Tipo
El relacionar las tablas de esta manera no hace más que ensuciar la DB y tener una falla de concepto
Aparte de sobrecargar en joins las consultas
entiendo por donde vas, pero una materia normalmente no va a ser solo el nombre de la materia, irá asociada a un grado y a más cosas
entonces pondrias un enum en todas las tablas donde se relacionen?
porque yo al menos no lo veo
Lo que va asociado al grado no es la materia, es el docente
La materia no existe en un grado sin un docente el cual la dicte
Por eso es la diferencia entre tipo y entrada
para mi son los dos los que estan asociados
El tipo tiene que ir fuertemente ligado con una tabla o un par, tiene que encerrar un rango de valores los cuales pueden existir en diferentes partes de la App pero no es el Enum el que entrega el valor
Si no las tablas que lo utilicen
Eso no lo decide la base de datos, lo decide la administración
La relación tiene que abstraerse a la aplicación
El desarrollador no tiene que decir "Matemáticas se da en Grado 1"
Listado de docentes en el grado, si querés sacar las materias seleccionas la materia del docente
A lo que voy, la materia no tiene que ir ligada a la clase o al alumno, va ligada al maestro porque de la administración deciden a que materia se dedica el docente, la administración decide cómo se conforman los grupos y los grados como así también las materias de los mismos
a ver todo esto al final es dependiendo del sistema que se quiera montar
En caso de extender el enum aplicas los cambios a la aplicación en general gracias a que esta aplicada en puntos claves y no en relaciones
yo estoy pensando en algo mucho mas generalizado que tu
para mi no llevar el control de las asignaturas me parece un error de trazabilidad en cuanto a estadistica (si es necesaria en algun momento)
me parece genial que la administración decida todo lo que tenga que decir
pero tendria que haber constancia en base de datos de todas las relaciones entre todo el sistema
no puedes depender de hacer 2 o 3 joins para sacar una informacion que deberia de ser instantanea
Estarías haciendo más Joins con la tabla Materias que con el Enum, supongamos que tenes la tabla Carreras y la tabla Maestros, el Enum no sale de ahí, querés sacar donde se aplica la materia matemáticas y lo haces sobre las carreras, querés los docentes? Mas de lo mismo que es un simple where
En mi opinión falta información sobre las necesidades. Tenemos unas tablas, mal hechas, pero no el objetivo de dichas.
A mi modo de ver, si podrias necesitar tener relacionado, o misma tabla Materia+Grado, e incluso podrias necesitar relacionar Materia con Alumno segun si un alumno puede cursar X materias o debe cursar todo un grado.
Asi como que un profesor puede dar ej; Matematicas en 8mo,9vo y Ciencias en 7to. En dicho caso si necesitas constatar que materias a que grados da.
yo coincido con @hidden hedge
Aparte de que falta mucha información, un sistema de este tipo no creo que sea suficiente mantenerlo a base de enum
para mi se queda corto de información
La misma extensión que le podes dar con una tabla se la podes dar con un Enum, la gran diferencia es que con un Enum no transportas el valor Materias a toda la DB y lo dejas en unas tablas fijas, con una Tabla lo generas es que puedas relacionar esa tabla con lo que se te cante (Incosistencia)
Tablas mal hechas como mal hechas no están, hay que diferenciar mal hechas con mejorables
A ver, mejorables hay cosas, pero esa tabla de Materias y Grados, creo que son mas que mejorables, pero la manera adecuda es esa, falta información sobre las necesidades concretas.
Con respecto a lo segundo, (Las relaciones n:m) son CTE o Stored Procedures, eso se modifica a nivel de requerimiento de la aplicación pero incluso con como paso las tablas se puede hacer
Las necesidades no dictan la estructura de la DB en gran medida, dichas necesidades se tienen que reflejar en las consultas y no en la estructura
Es como que yo te pida una casa alta y barata, vas a ir por construcción en seco y no en apilar ladrillos uno encima del otro. Hay que diferenciar entre aplicación y dominio
en sintesis las columnas no sirven para almacenar datos
me corriges?
Las columnas si sirven para almacenar datos, lo que esta erróneo es el tipo de dato
igual suele pasar y más si recién comienzas con las DBs
aah ok ok
entiendo
y como que tipo de datos por ejemplo si se puede usar para almacenar
Pues, seguramente me equivoque, pero en mi opinión si que tiene relevancia en la estructura, no puedes extraer los mismos datos si relacionas Alumno con Materias, a que si Relacionas Alumno con Grado y Grado con Materia.
Asi como puedes obtener diferente información si Tienes Profesor+Materia+Grado, a que si solo tienes Profesor+Materia
eso si se creo que materias hice al pedo una lista sabiendo que ese puede ir dentro de la tabla de profesores con especificamente el tipo de materia que enseña
dandole entrada ahi a materia
que al igual le puedo dar con turnos
verdad?
Pero que relación tiene el alumno con la materia si va ligada la materia al grado?
igual si quieren se puede hacer de esa manera, el problema es cuando se venga un refactor y toque mover muchas tablas en la DB
Pero ese era mi primer punto, va ligada al grado? Depende de lo que estudies un alumno puede hacer materias sueltas, y no el grado al completo.
Veamos, puede ir ligado a la app entera, desde turno hasta la persona que agrego al docente a la institución