Fw: listado complejo...o engorroso

Hola, gracias por responder, he estado mirando el link que me enviaste, yo uso la 9.04 (la última hasta donde yo sé), y soporta la eliminación de joins, aquí el problema es que por lo que les he preguntado(a los médicos, para intentar reducir este cacao) antes de escribir este mail, y según ellos, no hay genérica, hoy pueden ser 2 tablas, mañana 15, pasado todas, y lo mismo pasa con los campos, ellos quieren la mayor flexibilidad posible:(
Aunque después sólo necesito un campo aplicado a otra tabla diferente (de datos personales) de ahi sale el listado final...

Lo mismo en cuanto a los campos, he convencido para que quitaran algunos, la realidad es que son casi 800 campos en total.
Además de que no van a ser esos médicos solo, sino de otros lugares, lo cual según he leído documentación del link que me enviaste dificulta su uso, porque no hay tablas principales para que estos programas trabajen adecuadamente, al menos eso es lo que dice el "wiki" sobre este tipo de sistemas(ORM).
Esto me complica el tema, al no haber herramientas que me puedan ayudar.
No sé por donde empezar, bueno sí, pero de forma muy laboriosa.
La manera que veo es tabla por tabla, según las elija el médico o persona autorizada y en función de eso armar la consulta, no veo otra manera de eliminar tablas y joins.
Este listado volverá loco al pc del cliente, la servidor y al que se le ponga delante:)
Miraré mejor la info que me enviaste y a ver que saco en claro.
Gracias de nuevo
Un saludo
Suso

> Hola de nuevo a todos, tengo una duda (para no variar).
>
> Tengo que hacer un listado procedente de 33 tablas, en total son como 680 campos, de los cuales el médico puede seleccionar unos de una tabla, otros de otra, no necesariamente todas las tablas pueden estar envueltas, así como pueden o no ser todos los campos.
>
> Los datos que se deben obtener (al final) son sólo unos 10 como mucho (al menos por ahora y de una sola tabla), los datos (campos) obtenidos inicialmente debe ser uno sólo (cod_pac), puede haber de ese campo desde 0 hasta "x" registros.
>
> Ese cod_pac lo proceso al final con los datos de una sola tabla(la parte más sencilla).
>
> El problema es que debo coger la tabla de la que se obtenga menos registros en base a la selección de cada tabla.
> Es decir, la tabla A, tiene 10 campos(por ejemplo) y sus criterios de búsqueda, la tabla B, 50 campos y otros criterios, y así.
> Mi pregunta es , ¿ debo procesar primero cada tabla por separado para saber cual es la que menos registros cod_pac tiene en base a sus criterios de selección, y después hacer una consulta anidada tomando como inicio esa tabla( digamos que hacer el listado 2 veces), o hay otra manera menos "rebuscada" y que consuma menos recursos del server?, lo cual llevaría un tiempo.., no serán en total muchos registros, como 20 o 50.000 máximo creo.
> Evidentemente, no los traería todos de golpe, pero ese es otro tema

Tu idea es reimplementar el optimizador a mano, del lado del cliente.
Creo que no es muy buena, porque es mucho trabajo y seguramente
resultará lento.

Me parece que sería más práctico formar una consulta genérica que sea
capaz de atender una selección genérica, y usar una versión de Postgres
que sea capaz de hacer eliminación de joins.

http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.0#Join_Removal
http://akretschmer.blogspot.com/2010/02/join-removal-short-performance-test.html

Quizás no resulte hacerlo para las 33 tablas (no lo he intentado), pero
quizás te puedas arreglar para manejar los subconjuntos más comunes.