No estoy de acuerdo, cualquier tabla definada con SQL puede trabajarse en RPG
con las operaciones nativas CHAIN, SETLL, READ, etc.
________________________________
De: [email protected]
[mailto:[email protected]] En nombre de Sergio Luis
Puentes-Valladares
Enviado el: jueves, 24 de octubre de 2013 15:05
Para: forum.help400
Asunto: Re: SQL versus Nativo
Buenos Días
Debemos tener en cuenta que si creas las tablas con SQL, el acceso en
Free Rpg debe ser hecho a travéz de un programa Free Rpg
SQL, no puedes accederlo vía chain (campo1: campo2...) Tabla
Saludos
Sergio L. Puentes Valladares
Analista Programador Senior Plus AS400 (Rpg36, Rpg400, Rpgile, Free Rpg)
Analista Programador - Junior Java
Analista Programador - Junior PHP
Analista Programador - Junior Abap/4
Móvil +54 11 2452 9241 (Local, Buenos Aires, Argentina)
+54 911 2452 9241 (Internacional)
Skype Spuentes3452
El 24 de octubre de 2013 09:48, Pedro Molina <[email protected]>
escribió:
Hola.
Como dice Javier, con tablas definidas con SQL, además de lo
que el menciona, puedes también manejar la integridad referencial y acuerpando
lo del proceso de los millones de registros, yo también con PA (procedimiento
almacenado) hice una consulta sencilla donde leía una tabla y armaba una tabla
estadística a partir de la primera, solo que la tabla primaria contenía 165
millones de registros y te cuento que no era la más grande, pero para no
hacerte largo el cuento, estos registros se procesaban en 6.5 minutos, sin
exagerar como dice Javier, todo va en función de lo que quieras hacer y sobre
todo si haces un Módulo basado en tablas SQL, Procedimientos Almacenados
(programación SQL) hay que ver si tus compañeros le entienden a esto, porque yo
hice un Modulito en puro SQL y me tocó hacerlo de nuevo en la forma "nativa"
tradicional que todos conocemos y trabajamos por causa de que mis panas no le
entendían al asunto.
Saludos!!
________________________________
Subject: RE: SQL versus Nativo
Date: Thu, 24 Oct 2013 10:01:49 +0200
From: [email protected]
To: [email protected]
Si defines las tablas con SQL en lugar de DDS mejorará el
rendimiento de los programas "nativos". Un fichero creado con DDS por cada
lectura de un RPG se comprueba la validez de los datos (p.e. que un campo
numérico no tenga errores de datos decimales). En cambio en un fichero definido
con SQL este tipo de comprobaciones de realizan sólo cuando grabas y no cuando
lees.
Desde mi punto de vista, utilizar SQL en los programas te
ofrece mucha flexibilidad y los simplifica bastante. ¡Ojo!, hay que estar
atento en la construcción y optimización de esas consultas SQL.
Te voy a contar una anécdota. Hace un par de años necesitamos
un informe que atacaba un fichero que tiene unos 150 millores de registros (no
exagero). La persona que el programa no tenía conocimientos de SQL y optó por
hacerlo a la forma tradicional utilizando los lógicos de dicho fichero. En las
primeras versiones, calculamos que el programa sería capaz de entregar el
informe en más de 12 horas (una barbaridad). Después de muchos intentos de
optimización optamos por usar una sentencia SQL y el resultado se obtuvo en 30
minutos.
Sin embargo, esto NO es lo habitual y te toca revisar
contínuamente el "Asesor de índices" en aquellos programas en los que el
rendimiento y velocidad sean críticos.
Javier Mora
________________________________
De: [email protected]
[mailto:[email protected]] En nombre de Juan Carlos O.
Enviado el: jueves, 24 de octubre de 2013 8:29
Para: forum.help400
Asunto: SQL versus Nativo
Buenos días compañeros.
Quisiera conocer vuestra opinión sobre estas dos
posibilidades de utilización de la base de datos. Por centrar un poco el debate
planteo un par de preguntas:
* Al definir ficheros existe alguna funcionalidad
que el otro no tenga. Con SQL se puede hacer ... y con Nativo no, o viceversa.
* ¿Existen dos motores de acceso a la base de
datos o solo uno?
Os adelanto las gracias por vuestras opiniones sobre
este tema.
Saludos a todos.
____________________________________________________ �nete a
Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 �
Publicaciones Help400, S.L.
____________________________________________________
Únete a Recursos AS400, nuestra Comunidad (
http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.
____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.
