#Discutiendo las relaciones del pana

1 messages · Page 1 of 1 (latest)

blazing shell
#

Bueno, estás 50/50

#

pero tienes una fallas

wild flume
#

No soy explicando cosas, pero esa tabla Materias no está normalizada

regal snow
#

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

blazing shell
#

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

regal snow
#

Este problema de materias, te pasa exactamente igual con grados y turnos

#

es el mismo fallo de concepto

blazing shell
#

Sí, exactamente

#

También, las relaciones 1:M, la referencia debería estar de lado de M

tall aurora
#

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

regal snow
#

en mysql puedes usar tambien enum

tall aurora
#

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

tall aurora
regal snow
#

yo es que solo usaría enum en caso de saber que van a ser datos que nunca cambiarán

tall aurora
#

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

regal snow
#

si materias pueden añadirse y eliminarse comunmente, crearia la tabla aparte y relacionaba

tall aurora
#

En caso de que esa materia ya no sea válida para seguir agregando profesores con la misma, igual en grados

regal snow
#

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

tall aurora
#

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

regal snow
#

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

tall aurora
#

La materia no existe en un grado sin un docente el cual la dicte

#

Por eso es la diferencia entre tipo y entrada

regal snow
#

para mi son los dos los que estan asociados

tall aurora
#

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

regal snow
#

matematicas puede darse en 1 grado

#

pero no en quinto

tall aurora
#

Si no las tablas que lo utilicen

tall aurora
#

La relación tiene que abstraerse a la aplicación

regal snow
#

y si quieres hacer un listado de materias por grado

#

no tienes manera de hacerlo?

tall aurora
#

El desarrollador no tiene que decir "Matemáticas se da en Grado 1"

tall aurora
#

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

regal snow
#

a ver todo esto al final es dependiendo del sistema que se quiera montar

tall aurora
#

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

regal snow
#

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

tall aurora
#

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

hidden hedge
#

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.

regal snow
#

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

tall aurora
#

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)

tall aurora
hidden hedge
#

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.

tall aurora
#

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

tall aurora
#

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

south shard
#

me corriges?

tall aurora
south shard
#

aah ok ok

#

entiendo

#

y como que tipo de datos por ejemplo si se puede usar para almacenar

hidden hedge
#

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

south shard
#

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?

tall aurora
hidden hedge
tall aurora