Estimado:
Otro aporte adicional es los limites en la definición de los nombres de campos (columnas) en nativo, en SQL puedes definir campos mas claros, asimismo te recomiendo probar programar en SQL embebido donde no será necesario la declaración de los archivos (tablas) en la hoja de especificación del programa, asi que cuando agregas un campo nuevo o modificas la estructura de las tablas no tendras que estar recompilando los programas. Saludos Cristhian *De:* [email protected] [mailto: [email protected]] *En nombre de *Pedro Molina *Enviado el:* jueves, 24 de octubre de 2013 07:49 a.m. *Para:* [email protected] *Asunto:* RE: SQL versus Nativo 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]<[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.
