r/devsarg • u/Competitive_Ground_6 • 2d ago
backend Duda Base de datos y backend
En mi base de datos SQL
Tenia 3 tablas que compartian campos: Administrador, Profesor y Alumno. Asi que hice una tabla Persona donde estan todos los campos compartidos y relacione las respectivas tablas.
El backend lo estoy haciendo con Java con Springboot. Y siento que al haber hecho se esta complejizando el sistema en vez de simplificarlo. Es mas simple para crear las entities y manejar los services tener las tablas separadas.
Que deberia hacer? Cual es la forma correcta de manejar tablas en las cuales se repiten muchos campos?
8
u/coyoteazul2 1d ago
mantener la integridad de los datos siempre es lo principal. los usuarios se arreglan si el sistema es lento o si la informacion no se presenta exactamente como quieren. pero si ven que el sistema tiene datos incorrectos, nunca mas van a confiar en el sistema.
el ejemplo mas sencillo es, que pasa si tenes una persona que es administrador, alumno y profesor a la vez, se cambia el genero y ahora Roberto pasa a llamarse Carlota? Vas a modificar el nombre en las 3 tablas?
Tenes que considerar que el mantenimiento del sistema no necesariamente vayas a hacerlo vos. Puede ser otro desarrollador, o podes ser vos mismo dentro de muchos años cuando ya no te acuerdes a detalle que hiciste hoy y porque lo hiciste asi
4
u/BealeStBluesBoy 1d ago
Tiene todo el sentido la tabla persona, lo que podes hacer para simplificar un poco las cosas es una vista. Si estás usando un orm probablemente tenga una función para eso.
2
u/nrctkno 1d ago
Mira, el hecho de que se repitan campos no es condición suficiente para consolidarlos en una misma tabla, pero es un indicador de que podría ser conveniente eliminar los atributos duplicados. Eso se llama llevar el modelo a primera forma normal (1NF).
En tu caso puntual, lo que voy se te complica en lógica de negocio mañana te simplifica otras, ej. cuando quieras saber cuántas personas tenés en tu sistema ya no tenés que hacer administradores U profesiones U alumnos. Pero más importante, le da otra significación a la entidad persona/usuario adentro de tu negocio.
1
u/maullidothethird 1d ago
Armate un gráfico de entidad relación o de las tablas en si. Es más rápido para todos verlo se esa manera
1
u/KaspaTal 1d ago
La tabla persona, debería ser una vista, no una tabla. Porque si actualizas las otras, no actualiza a persona y ahí tenés un error grave de consistencia. En cambio la vista es como una query que cada vez que llamas a esa vista, le pregunta a las otras por sus datos, no es que "se guarda en memoria", el problema de eso es que metes lógica de negocio en la db, pero esa es otra charla
1
u/KingOfMates 1d ago
Todo depende.
En qué beneficia a tu sistema que tengas la entidad persona? En algún momento usas la entidad persona, solamente o siempre usas una de las otras 3?
Podes tener alumnos que sean profesores al mismo tiempo, por ejemplo?
Planeas que en un futuro pueda tener un uso y te beneficie en algo?
Si a cada rato que vas a buscar un dato, tenés que consultar 2 tablas en vez de una, quizás termines haciendo más lento todo y a la larga te perjudique.
Desde mi punto de vista todas las desiciones de diseño tienen que estar justificadas desde la funcionalidad y no solamente porque la teoría dice que tiene que ser así.
Por lo menos yo desde ese lado soy más pragmatico.
1
u/jorgedx15 1d ago
El típico problema de cuando pasas de modelo de objetos a un modelo relacional, parte del Impedance mismatch. Tenés 3 opciones para resolver tu herencia, un Single Table, Table per Class o usar JOINED. Todo depende de la cantidad de atributos que compartan y del costo que implique hacer una consulta HQL. Como tenés muchos atributos compartidos capaz te conviene un Single Table o un JOINED
0
u/Quaaaaaaaaaa 1d ago
En esos casos crea nuevas tablas para cada dato, luego conecta cada tabla a su respectiva entidad e interconecta todo.
Lo importante es que funcione en el momento, de todas formas la empresa se va a fundir a los años
-1
u/kaiser_ajm 1d ago
Es una tabla, personas. Y hasta podes meter empresas. Luego un booleano (es profesor, es alumno, etc)
1
u/CM_Lucas 21h ago
noo eso escalaría muy poco jajaj tiene varias opciones dependiendo el caso, puede agrupar columnas en una tabla Persona
Persona
- id (pk)
- nombre
- apellido
- dni
- fechaNacimiento
Alumno
- id (pk)
- persona_id (fk)
- dato/s propios del alumno y el mismo concepto para tablas Profesor y Administrador
Otra posibilidad aunque acopla mucho, es que si Alumno, Profesor y Administrador tienen practicamente los mismos datos podes hacer
Persona
- todos sus datos comunes
- rol_id (fk)
Rol
- id (pk)
- nombre
si mañana el campo profesor necesita mucho mas campos capaz te conviene separarlo a otra tabla y que tenga una referencia a persona, como antes pero todo es un depende
1
u/kaiser_ajm 19h ago
Así lo tiene Odoo, escalado millones de empresas
1
u/CM_Lucas 18h ago
tendrás el repo, o noticia o donde viste que tenga las tablas así? sino esta re contra atado a un dominio y poco escalable si posta es así
si vos me decís porque en el panel de admin te tiene checked de cada rol, eso no es un booleano, si vos me decís que persona usa un metodo para saber si es_alumno() tranquilamente puede ser la division por roles que nombre antes y es un metodo que llama a su rol asociado,
tipo posta me parecería raro que lo tengan tan desnormalizado jajaja
1
u/kaiser_ajm 11h ago
En un hospital teníamos odoo con las tablas personas (partner) y médico y paciente. Pero resulta que habían médicos que podían ser pacientes. Teníamos relaciones duplicadas por todos lados. Así que migramos a una sola tabla y todo se unificó sin problemas.
1
u/kaiser_ajm 11h ago
No se tomen todo tan taxativo. La normalización te dice que no guardes el campo "edad" porque ya tenés el campo "fecha de nacimiento", eso es un punto, pero puede haber un caso que te pueda convenir guardar el campo en DB. Un ejemplo puede ser cantidad de ventas, quizás tenés un dashboard qué lo uses Todo el tiempo y te conviene guardar el campo que llamar a un método 100 veces por día, X dar un ejemplo.
-2
u/ojoelescalon Desarrollador de software 1d ago
Una tabla de persona con administrador_profile, profesor_profile o alumno_profile. Se llama Polymorphic Associations el patron, es bastante usado y hay informacion por todos lados para aprender como hacerlo.
-3
u/rafadizeo 1d ago
Año 2026 creo que es mejor preguntarle a la IA a la que le podés dar todo el contexto que en un foro
2
23
u/loscapos5 1d ago
Eliminar campos repetidos y usarlos en las tablas correspondientes.
Si tenés Persona, y las 3 otras tablas también representan personas, entonces eliminar columnas que se repitan, y tener solo columnas que tengan los datoa relacionados a la tabla donde están, y tener una foreign key apuntando a la tabla que tiene datos restantes.
Por ej: En Persona vas a tener ID, Nombre, Apellido, Edad, etc. Entonces en Alumno vas a tener ID, ID_Persona, Legajo, fecha inscripción , etc. No vas a tener datos como nombre porque, si los necesitas, vas a buscarlos desde la tabla Persona, usando como referencia el ID_Persona.