Ver Mensaje Individual
  #4 (permalink)  
Antiguo 11/08/2009, 16:32
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: Consulta en forma de horario

Cita:
en si solo necesito hacer la consulta para que me muestre mi detalle en formato Lunes,Martes,Miercoles...
En sí sería lo mismo que un SELECT * FROM....
Lo que te aconsejan es cierto: Sin importar como hagas la consulta, para darle formato de horario semanal, te conviene hacerlo en la aplicación.
Cita:
lo demas son agrupaciones o bueno no se si tambien entra un when case para formar
En realidad no. La consulta de este tipo es mucho más compleja de lo que parece. No son agrupaciones lo que tienes que hacer sino varios JOIN que te deben devolver cada columna de día de semana, para finalmente hacer agrupaciones.... Es demasiado complicado.
Cita:
hora Lunes
08:00 - 09:00 PRF0000001
CUR0000005
Este ejemplo, directamente está fuera de discusión: Es un estilo de reporte que solamente puedes hacer vía aplicación.

En cuanto al otro caso, miralo así:
  • De cada día debe devolverte la asignación en cada horario de cada profesor, y que te devuelva nulos o vacíos donde no haya horarios asignados.
  • Como los horarios se repiten en cada día, pero no las asignaciones, deberás realizar una consulta por cada día para obtener las asignaciones de los diferentes dias.
  • El resultado de cada día debe ser combinado en una tabla con los de los otros días. Esto implicaría el uso de JOIN para unir el resultado de una subconsulta para lunes, otra para el martes y así sucesivamente.
  • La tabla final devolvería, siendo n el numero de registros, n^5 ó n^6 registros, que finalmente deberán ser agrupados, para reducirlos a los necesarios.
  • Esta operación debe hacerse separadamente para obtener los de cada docente, los de cada alumno o los de cada curso... en una sumatoria de consultas casi interminable.
¿Se va entendiendo la idea? El problema es que semejante consulta (que contiene de 5 a 6 subconsultas), será un atentado a la performance de la aplicación.
De allí el consejo de resolverlo en la aplicación, donde se reduciría a recuperar tres tablas y usar dos FOR/NEXT, poco más o menos.

Hazlo en la aplicación...
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)