Estoy de acuerdo contigo, pero no del todo. Cuando se descubre la potencia del SQL y, sobre todo, del SELECT no lo cambio por otra cosa. Te pongo un ejemplo: en el caso que ha provocado este hilo, tengo que procesar y resumir unos datos que con un programa RPG me obliga a tener un lógico creado o clasificar con OPNQRYF el archivo; constuir varios bucles y archivos intermedios; realizar cálculos por totales; generar el informe. Sin embargo, con el SELECT he conseguido hacer casi todo de una sola vez. El programa es un poco más complicado, pero me ha evitado muchas horas de programación.
________________________________
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Técnico
(grupCONSULTOR, s.a.)
Enviado el: viernes, 28 de marzo de 2008 11:02
Para: 'forum.help400'
Asunto: RE: SQL vs SQL -- curiosidad
Yo he podido comprobar que un SQL que utilice bien las vías lógicas y
los EVI's que se hayan creado es mucho más rápido que un RPG con READE y
READ's. Es más, cuando te generas tablas intermedias para procesos, normalmente
es más rápido ir creando tablas temporales con pocas restricciones que meterlo
todo en un solo SELECT.
Jorge Merino
e-mail: [EMAIL PROTECTED]
Tél: 971 467 912
Fax: 971 770 751
________________________________
Este mensaje se dirige exclusivamente a su destinatario y puede
contener información privilegiada o confidencial y/o datos de carácter
personal, cuya difusión está regulada por la Ley Orgánica de Protección de
Datos y la Ley de Servicios de la Sociedad de la Información. Si usted no es el
destinatario indicado (o el responsable de la entrega al mismo), no debe copiar
o entregar este mensaje a terceros bajo ningún concepto. Si ha recibido este
mensaje por error o lo ha conseguido por otros medios, le rogamos que nos lo
comunique inmediatamente por esta misma vía y proceda a su eliminación
irreversible. Las opiniones, conclusiones y demás información incluida en este
mensaje que no estén relacionadas con asuntos profesionales de nuestra empresa
no están respaldadas por la misma.
This message goes exclusively to his addressee and can contain
privileged or confidential information and / or information of personal
character, which diffusion is regulated by the Organic Law of Protection of
Information and the Law of Services of the Society of the Information. If you
are not the addressee indicated (or the person in charge of the delivery to the
same one), it must not copy or deliver this message to third under any concept.
If it has got this message for mistake or has obtained it for other means, we
ask him to communicate it to us immediately for the same route and to proceed
to his irreversible elimination. The opinions, conclusions and other
information included in this message that are not related to professional
matters of our company are not endorsed.
________________________________
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de [EMAIL
PROTECTED]
Enviado el: viernes, 28 de marzo de 2008 10:19
Para: forum.help400
Asunto: Re: SQL vs SQL -- curiosidad
por ejemplo , READE de tres campos clave .
Y si no es molestia READ del fichero entero ..
Saludos y Gracias.
En/na Javier Mora ha escrit:
¿Qué atrevido eres? ;-)
¿El READE de cuantos campos de clave? ¿De registros del principio, en
medio o del final?
De todas formas, al no tener más vías de acceso que la del archivo
físico, creo que irá muy rápido. Haré algunas pruebas.
________________________________
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de
[EMAIL PROTECTED]
Enviado el: miércoles, 26 de marzo de 2008 14:18
Para: forum.help400
Asunto: Re: SQL vs SQL -- curiosidad
por curiosidad , ya que estas metido en el tema:
¿ Podrías comprobar cuanto tarda en leer los millones de
registros mediante un programa RPG IV ? . Con SETLL I READE por ejemplo .
Gracias y saludos.
En/na Javier Mora ha escrit:
Hola Alex:
Bueno, a no ser que lo haya creado el sistema, el archivo
físico con los 100 millones de registros no tiene ningún índice, sólo la vía de
acceso creada con el físico (DDS). Lo que apuntas podría ser cierto, incluso si
el sistema creara un índice temporal, pero comprobé después de ejecutar el
SELECT con RUNSQLSTM, QM o RPG, el tiempo de ejecución con STRSQL siendo los
resultados los mismos.
Podrían ser PTFs. Estoy en V5R4 con el nivel 7282 del PTF
acumulativo. El grupo para DB2 UDB está en el 13. Consultaré el link que me
indicas.
Sobre el asesor también visitaré la reseña que indicas.
Un saludo,
Javier Mora
________________________________
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En
nombre de alex martinez
Enviado el: martes, 25 de marzo de 2008 11:50
Para: forum.help400
Asunto: Re: SQL vs SQL -- curiosidad
Si estás en V5R4 puede que el sistema te haya
recomendado un indice. Es mucho especular, pero puede que durante tu primer
intento el indice no estuviera disponible y en la siguientes consultas ya
estaba preparado....
Aunque están apareciendo contínuamente PTFs sobre
OSP-DB PERFORMANCE como por ejemplo
http://www-912.ibm.com/a_dir/as4ptf.nsf/ALLPTFS/MF43280
Sobre el asesor de indices publiqué una entrada sobre
esta novedad en mi blog
http://www.ajut400.com/2007/06/asesor-de-ndices.html
El día 25/03/08, Javier Mora <[EMAIL PROTECTED]>
escribió:
Hola a todos:
Esta nota es sólo para exponer una curiosidad que me ha
surgido al utilizar SQL. Os explico.
He construido una sentencia SELECT no muy complicada
que toma datos de cuatro ficheros, dos de ellos con 15 millones y casi 100
millones de registros. Mi método de trabajo consiste en probar primero los
resultados desde una sesión interactiva de SQL (STRSQL). Después de intentar
optimizar en varias ocasiones la sentencia, desde STRSQL no he conseguido que
termine la ejecución (en todas las ocasiones esperé más de una hora, hasta que
cancelé el proceso).
Esta situación me desesperó un poco. En equipos
anteriores la ejecución de trabajos por lotes ha ido siempre más rápida
(hablamos de programas no interactivos). Cogí la misma sentencia SELECT y la
ejecuté con el mandato RUNSQLSTM en batch. ¡Oh, que sorpresa! La ejecución
terminó en no más de un minuto. Como la sentencia SQL la tuve que cambiar para
dejar los resultados en un fichero pensé que podría tener algo que ver. Luego
intenté ejecutar RUNSQLSTM en interactivo y, ¡qué casualidad!, el resultado fue
el mismo (o casi): entre un minuto y dos en ejecutarse.
Hice una prueba más, para disipar alguna duda. Utilicé
la misma sentencia SELECT en QM y los resultados fueron similares.
Finalmente, incluí el SQL en el programa RPG desde
donde debía trabajar con las filas devueltas y su ejecución no fue más allá de
los dos minutos.
¿Es esto sólo una curiosidad? ¿Alguien tiene o se le
ocurre una explicación? Desde mi punto de vista, una sentencia SQL debería
ejecutarse a través de los mismos recursos desde STRSQL o cualquier otra
utilidad. ¿Estoy equivocado?
Un saludo
Javier Mora
__________________________________________________
Forum.HELP400 es un servicio m&#225;s de NEWS/400.
&#169; Publicaciones Help400, S.L. - Todos los
derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
--
Mi blog sobre as400
http://www.ajut400.com
________________________________
__________________________________________________
Forum.HELP400 es un servicio m&#225;s de NEWS/400.
&#169; Publicaciones Help400, S.L. - Todos los derechos
reservados
http://www.help400.es
_____________________________________________________
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
________________________________
__________________________________________________
Forum.HELP400 es un servicio m&#225;s de NEWS/400.
&#169; Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400
<<image001.jpg>>
<<image002.jpg>>
__________________________________________________ Forum.HELP400 es un servicio m&#225;s de NEWS/400. &#169; Publicaciones Help400, S.L. - Todos los derechos reservados http://www.help400.es _____________________________________________________ Para darte de baja visita la siguente URL: http://listas.combios.es/mailman/listinfo/forum.help400
