como unir dos tablas en mysql

[ciranoneitor]

Hola a todos.

Tengo una consulta que realizar, me he pasado toda la noche sin lograr realizar esto.

Yo dispongo de 2 tablas.

AlumnosJovenes y AlumnosAdultos

necesito tener una tercera tabla que se llame alumnosgeneral.

que constara de solo 2 columnas

idgeneral - idalumnos(jovenes-adultos)

Necesito saber si puedo hacer que cuando yo cargue un alumno en las tablas de alumnosjovenes, y alumnos adultos, el ultimo id se agregue a la tabla de alumno general, si ejecutar ningun tipo de script en php.

Haber si me explico bien. cargo un alumno en cada tabla:

AlumnosJovenes
ID: 105
Nombre: Juan
Apellido: Pendorcho
Apellido 2: Doblado
Otros datos: Otros datos.

Alumnosadultos
ID: 75
Nombre: pepeto
Apellido: Agapito
Apellido 2: barriga
otros datos: otros datos

Esta dos tablas de arriba tienen que cargar sus id en la tabla de abajo, de forma automatica, se podra hacer con entidad-relacion(no lo he logrado)

AlumnosGeneral

IDgeneral - idalumnos(jovenes-adultos)
50 --------------------- 105
51 --------------------- 75

Espero haberme explicado.

Saludos a tods.

[Cuervoo]

Sin php, podés usar procedimientos almacenados.

[ciranoneitor]

Che cuervo, voy a buscar lo de procedimientos almacenados, pero gracias por las respuesta, es la segunda vez que me respondes algo. Bien lo tuyo.

si no encuentro como hacerlo, te vuelvo a pregunta.

[gnzsoloyo]

Necesito saber si puedo hacer que cuando yo cargue un alumno en las tablas de alumnosjovenes, y alumnos adultos, el ultimo id se agregue a la tabla de alumno general, si ejecutar ningun tipo de script en php.

En realidad lo puedes plantear de las dos formas: O mandas a hacer dos inserts, donde el primero va a una u otra tabla según sea el que debe, y lo haces por PHP, o bien creas un stored procedure y realizas toda la lógica allí, es decir, los tres inserts y su resolucion implementado en ese mismo SP.
Esta última forma es en realidad la mejor, porque haces que la aplicación sólo deba acceder a una sola llamada, mientras que la resolución de jovenes y adultos está encapsulada en la base.
De todos modos desde el punto de vista de un diseño de bases de datos, el planteo está mal, porque lo que existen son alumnos que pueden ser jóvenes o adultos, por ende, la condición de Alumno precede a su edad, y como consecuencia debe hacerse primero el alta como alumno, y en la de jóvenes y/o adultos sólo poner la FK más datos diferenciales.
Ahora bien, un detalle más: Si las tablas que propones AlumnosJovenes y AlumnosAdutos, tienen los mismos atributos, entonces todo el esquema es incorrecto, al menos desde la perspectiva de bases de datos, por cuanto su condición de Joven o Adulto es un atributo calculable (la diferencia entre su fecha de nacimiento y la actual), y por tanto deberías resolverlo en la aplicación, o al momento de realizar las consultas.
Sólo tiene sentido diferenciar tablas de Jovenes o Adultos, si hubiese atributos que uno tenga y el otro no, y de cualquier forma deberían ser atributos obligatorios (incluso esto podrían no requerir diferenciarlos entre tablas). Y sólo los atributos diferenciados irían en esas tablas. No el nombre, apellido u otros datos comunes.

Ten muy en cuenta que no se debe analizar el esquema de bases de datos como una representación del sistema de clases de una aplicación. La base de datos alimenta de datos a la aplicación, pero no es un reflejo fiel de las clases en ella.

[ciranoneitor]

Hola GNSsoloyo, primero entiendo lo que dices que si la dos tablas alumnos tienen los mismo atributos. el tema es que no, si no, que en alumnosjovenes, o menores de edad, hay 7 u 8 atributos mas. por ejemplo, en alumno joven, tengo ademas de los datos del alumno, los datos del responsable, y un otros permisos mas como tomar de fotografia y eso.

Son dos formularios totalmente distinto.

porque creo una tercer tabla. por el motivo que cuando quiero listar las dos tablas, osea todos los usuarios, tanto adultos como jovenes, yo puede ordenar por ID.

Entonces la idea, no se si esta bien o mal, soy bastante novato.

la idea es que cuando inserte, un dato en la tabla jovenes, y en la tabla alumnos, esto se actualicen en la tabla general donde el id de general se autoincremente. pero se que si yo tomo el id: 5, sea en realidad el ID del alumno en la tabla alumnosjovenes.

Si existe otra forma que supongo que si, estaria feliz de saberlo.

Soy novato como les decia, y la mayor parte de la aplicación la realizo a errores jjeje

[gnzsoloyo]

En realidad, en todo el problema pueden manejarse dos o tres tablas, dependiendo de algunos factores, y en ningún momento se necesita separar en tablas a los jovenes de los adultos, sino manejarlo en función de lógica:
Alumno(idAlumno, nombre, apellido, documento,fechaNacimiento, ... otros datos)
ResponsableAlumno(idResponsable, idAlumno, nombre, apellido, FechaAlta, FechaBaja, otros datos)
PermisosAlumno(idAlumno, idResponsable, idPermiso, FechaPermiso, BajaPermiso)
Permisos(idPermisos, NombrePermiso, DescripcionPermiso, Obligatorio, tiempoVigencia, ortos datos)

Un esquema como este permite administrar sin mayores problemas algo como lo que dices.
- Para permitir un alta en ResponsableAlumno, tu sistema debe verificar que el alumno que se indicará en ese caso es menor de edad.
- Para permitir completar el alta de un Alumno menor de edad, deberá ingresar obligatoriamente un Responsable, y los permisos que sean obligatorios.
- Si se cambia un responsable, se pone la fecha de baja, y se pone fecha de baja a todos los permisos en que ambos estén relacionados.
- Si la existencia de un Responsable es necesaria, no se podrá dar de baja a menos que sea por una gestión de alta de un nuevo responsable.
- otras cosas más que se pueden deducir o establecer por análisis.

Todo este tipo de esquemas se soporta en la base de datos, pero no se deben derivar las validaciones a la base, son obligaciones de la aplicación, no de la base. Esas reglas pueden estar parametrizadas en la base, pero cuando los datos llegan a la base ya deben estar verificados.
Es muy común en los programadores que se inician pensar que todo lo que sea datos es tema de bases de datos, y eso no es cierto.
La base debe proteger la integridad y consistencia, pero no puedes poner todas las reglas y restricciones de la lógica de negocio en ella. Eso implicaría un exceso de acoplamiento, que a la larga es pernicioso. Esas pertenecen a la aplicación (lo se por experiencia, trabajo en un sistema de altísima complejidad, que tiene centenares de niveles de validación, los cuales toman parámetros de base, pero validan en aplicación).
Hay razone s de peso de por qué se programa de esa forma, pero es mejor hacer las cosa bien de entrada, y no meter errores que luego requerirán rehacer todo para hacerlo bien.

[ciranoneitor]

Hola que tal.

en ningun momento intento evitar verificacion de nada. ni realizar una verificacion con la base de datos. el motivo de las 3 tablas era para tener todo realmente ordenado, alumnos adultos, por lado, y alumnos jovenes por otro, y la tercer tabla para llevar el id de las dos tablas de alumno en una sola.

Saludos y gracias

[gnzsoloyo]

Pues lo que te estoy proponiendo es un avance sobre eso, que puedo asegurarte que hará funcionar todo mejor, y con consultas mucho más eficientes.
En tanto las clases controladoras de entidades y actividad estén bien desarrolladas, un conjunto de tablas como lo que te digo te otorgaría flexibilidad, además de posibiilidad de escalamiento sin necesidad de andar rehaciendo todo.
Pero, bueno, es tu decisión.