Javier aqué mi humilde opinón:
1) Respecto a tu primera duda, el hecho que uses tablas creadas con DB2
no significa que tus programas tengan que ser RPGSQL no tiene nada que
ver, igual puedes usar la programación tradicional con los read y chain
clasicos..con RPG Free o lo que sea. Ahora, es cierto que en estos
programas no podrás ver el impacto de las tablas incluidas en SQL
incrustado,esto ciertamente es una desventaja; pero la ventaja es que
tampoco tendrás que recompilar dichos programas cuando tu tabla cambie.
2) Un archivo logico es diferente a un indice. Desde mi punto de vista
un archivo lógico es un mix entre un indice con una vista. Lógicamente
con los indices no podrás hacer filtros como lo hacias con tus archivos
logicos DDS. Pero es un tema de estilo de programación al que te llegas
a acostumbrar. Por ejemplo si un logico tiene un filtro, ejemplo
ESTADO=1, entones si quieres verlo como indice tendrás que crear un
indice con el campo ESTADO y accederlo con el valor de 1. Yo he cambiado
varios programas así y bueno es trabajo que realizas pero ganas a futuro.
3) Considero que SI. En la empresa que trabajo diseñamos un plan de
adecuación a DB2 a cuatro años, para migrar completamente. (no tengo el
dato actual, pero creo que tenemos más de 3 mil tablas y varios miles de
programas con aprox. 700 usuarios en linea) Las tablas nuevas las
hacemos integramente en DB2 en una biblioteca nueva, y bajo un nuevo
estandar de denominación de objetos de base de datos usando toda la
potencia de DB2 como los indices, vistas, triggers, funciones,
procedimientos, etc. y las tablas antiguas (archivos fisicos) se van
pasando al nuevo esquema.
4) Creo que NO. Es un temos natural. Es logico pensar en la cantidad de
tabajo involucrado; pero estoy seguro de que vale la pena dados los
beneficios de usar DB2 y el estandar SQL, los cuales te brindan
escalabilidad a futuro incluso si desearas llevar tu base de datos a
otras plataforma en el futuro (no lo creo).
Como comentario final, investigué acerca de poder automatizar el tema
del diseño de base de datos a través de una herramienta de modalamiento,
Nosotros lo hacemos integramente con Erwin DataModeler, para el cual
creamos algunas macros para automatizar el tema de la denominación
interna (nombres nativos) y denominación externa (nombres SQL), el cual
hemos sabido aprovechar bastante. No tengo intenciones de hacer
propagandas ni nada a la herramienta, pero considero que es
aceptablemente buena, pues nos permite ver el modelo lógico de nuestra
base de datos (como quieres que se llamen tus tablas: clientes,
productos, etc) y luego la llevas al modelo fisico (según tu estandar de
denominación)... incluso colocamos algunos CLs en las macros para
incluir a las tablas en los journales, entre otras cosas. No he probado
otras herramientas de modelmiento de base de datos; pero supongo que
deben tener lo suyo.
Buenos son algunas ideas
Saludos
_________________________
Carlos Augusto Correa García
Desarrollo de Sistemas
CMAC PIURA S.A.C
Javier Mora escribió:
Hola a todos:
Llevo más de 15 años desarrollando software sobre AS/400 e iSeries en
RPG y DDS. De hecho, hoy todavía sigo utilizando DDS tanto para
archivos de base de datos, pantallas e impresión. Desde mediados de
los 90 llevo leyendo artículos sobre las iniciativas de IBM para que
los desarrolladores empleen SQL en lugar de DDS/operaciones E/S en sus
aplicaciones. Muchos de vosotros ya habéis dado el salto desde hace
años. ¿Porqué yo todavía ni le he intentado?
Recientemente he leído un artículo más sobre este asunto, en el que
apunta una serie de razones que me convencen. Pero aún así, sigo con
ciertas dudas existenciales. Tengo claro que podría empezar por
sustituir archivos físicos y lógicos por tablas e índices. Ganaré en
mucha en potencia expresiva. Lo que no tengo tan claro es el empleo de
sentencias insert, update, delete para sustituir los write, update o
delete de la E/S tradicional de RPG.
Mis dudas son sencillas y simples:
1) Por el estilo de programación que hemos utilizado toda la vida,
empleamos herramientas del estilo de DSPPGMREF para analizar el
impacto de los cambios que queremos realizar en la aplicación. Por
ejemplo, añadir un campo en un archivo, la división de un archivo en
dos (formas normales), etc. Este mandato tiene controlado los
programas llamados, programas de servicio y los archivos utilizados
por los programas de aplicación. Si empiezo a utilizar SQL
"incrustado" en mis programas voy a perder esta herramienta, ¿existe
algún otro medio para realizar un análisis de impacto? No quiero
realizar búsquedas en los fuente. ¿Estoy equivocado en esta
apreciación? ¿Gano más que pierdo?
2) Siempre he creído tener claros conceptos como archivos físicos,
lógicos y vías de acceso, pero ahora se me entremezcla todo con SQL.
No se porqué. ¿Qué diferencia existe entre un índice y una vía de
acceso o un lógico?
3) ¿Es realmente factible un entorno mixto? Es decir, dejar las
aplicaciones actuales trabajando con E/S nativa pero los archivos
definidos ya en SQL. ¿Es necesario realizar algún ajustes en los
programas ya en producción?
4) ¿Estoy paranoico? ;-)
Lo dejo aquí. Creo que me he enrollado demasiado. No sé si los ya
lleváis trabajando con SQL años tuvisteis estas dudas existenciales.
Un saludo a todos y gracias por "escuchar" mis lamentos. Cualquier
comentario será bienvenido.
*Javier Mora*
--
Este mensaje ha sido analizado por *MailScanner*
<http://www.mailscanner.info/>
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
MailScanner agradece a transtec Computers <http://www.transtec.co.uk/>
por su apoyo.
------------------------------------------------------------------------
__________________________________________________
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
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
For all your IT requirements visit: http://www.transtec.co.uk
__________________________________________________
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
