Coloco entre
comillas base de datos porque en realidad DDS es un manejador de archivos y no
un manejador de base de datos.
Crear Bases de datos
con DB2 tiene una serie de validaciones
automáticas suministradas por el DB2 que impiden de alguna manera la generación
de algunos “Frankenstein”; en cambio, la libertad del uso de las DDS si permiten la proliferación de algunas
creaturas terroríficas que deambulan en los pantanos de los sistemas de las
organizaciones
1.-El Diccionario de Datos.
El uso del diccionario de
datos que tuvo su auge en décadas
pasadas ha pasado a ser, en varias instalaciones, una colección mas en el baúl de los recuerdos. El Diccionario de datos
permite mantener la consistencia e integridad de la data. En algunas
instalaciones vemos por ejemplo, que unos archivos tienen el código de país de
tres posiciones alfabéticos, otros los tienes de dos posiciones numéricos y
otros de seis posiciones alineados a la izquierda utilizando solo los primeros
dos caracteres. Para evitar esta variedad de definiciones que rompen con la
consistencia de la base de datos es importante y fundamental utilizar un diccionario
de datos.
2.-Normalización de las Bases de Datos.
Hay material de estudio
académicamente certificado que explica como definir una base de datos siguiendo
las reglas normalización de primera forma normal hasta quinta forma normal. Es
bueno desempolvar lo que aprendimos en las instituciones y llevarlo a las
mejores prácticas en nuestros sitios laborales. En los siguientes artículos
vamos a ver la aplicación de la normalización de las bases de datos en el desarrollo
de programas RPG usando DDS.
3.-NO colocar índices en los archivos
físicos.
Colocar claves en los
archivos físicos retarda los procesos de recuperación, copia y salvado de la
data. Incluso retardan el tiempo de respuesta de los procesos. Es preferible
utilizar lógicos, SQL o cualquier otro medio de acceso indexado que satisfaga
esa necesidad de ordenamiento.
4.-Deje algunos campos comodín.
Dada la dinámica de los
cambios en las normas y reglas del negocio, algunas veces es imposible predecir
la necesidad de expandir un archivo creándole mas campos y cuando las
modificaciones que requiere el negocio nos lleva a la necesidad de crear campos
adicionales preferimos crear otras tablas o archivos que viene a ser la
“extensión” del archivo base. Es conveniente crear algunos campos extras de
tipo carácter y numérico que permita prevenirnos de modificaciones dramáticas a
futuro, que involucre la recompilacion de varios programas que depende de las
definiciones de los archivos.
Aunque algunos prefieran
crear tablas adicionales, la consulta de estas tablas en procesos nocturnos
(hacer chain una y otra vez) puede retrasar el tiempo de respuesta.
5.-
Aún utilizando el
diccionario de datos, los archivos que reposan sobre él en cuanto a su
definición pueden tener sus propios nombres de campos según el criterio del
analista o las normas de desarrollo del departamento de sistemas.
¿Qué es eso de la
consistencia en los nombres?
Por ejemplo para los
campos que sean código utilice las tres primeras posiciones de la izquierda
como COD o si lo prefiere CD o
de cualquier otra manera. Cualquier sea su elección mantenga esa nomenclatura
en todos lados. Si se trata de una descripción y decide utilizar DES
utilice DES a lo largo y ancho de la base de datos.
Aunque una longitud de 6
posiciones es bastante corta para describir el concepto del uso de un campo, el
respeto por las convenciones de uso y nomenclatura establecidas por el
departamento de sistemas y de base de datos, facilita al analista entender
rápidamente de qué se trata el contenido de la data.
En el siguiente enlace conseguirás mas información sobre creación de base de datos publicada en otros artículos de este mismo blog.
Haz click aqui: Bases de Datos
En las
próximas entregas voy a ilustrar la definición y el uso paso a paso de una base
de datos adaptado a DDS y para desarrolladores RPG además de otras
recomendaciones.
Si te pareció interesante, reenvíalo a un amigo
haciendo click en el sobrecito que está al final del artículo. El conocimiento
es valioso, compártelo.
Autor: Ing. Liliana Suárez
2 comments:
If Google Translate is translating your post correctly you are saying that you should not key a Physical file (PF)as it slows the process if the file has to be restored.
Are you sure that it takes longer to restore a PF with a key than it does for an unkeyed PF then has to rebuild the index of the Logical file (LF) that contains the primary key. I have tested this and this is slower.
As you do not have to restore you data very often I would say that the advantages of keying PF out ways the benefit of not.
hola Simon!, ya no se usan los físicos con claves porque aparte de los problemas de restauración, es mas difícil trasladar el archivo a otro sector del disco cuando el disco duro se corrompe. El proceso de restauración del archivo en esos casos en los que se dañaron los "tracks" es mucho mas difícil con un físico indexado. Gracias por tu aporte!
Post a Comment