Trabajando como desarrollador backend en el ecosistema IBM i, la gestión de datos es nuestro pan de cada día. Hoy quiero compartirles un repaso rápido sobre uno de los pilares del sistema: los Physical Files (PF) o Archivos Físicos.

Básicamente, un PF es el objeto donde residen físicamente nuestros datos estructurados.

📌 Conceptos Clave

  • Límites: Un archivo físico tradicional puede contener un máximo de 8,000 campos y hasta 120 campos clave.
  • Comando base: Clásicamente, utilizamos el comando CRTPF para crearlos.

🏗️ La estructura interna (Niveles DDS)

Cuando definimos un PF usando DDS (Data Description Specifications), el código se divide en cuatro niveles principales:

  1. Nivel de Archivo (Opcional): Define las reglas para todo el archivo. Aquí decidimos si las llaves deben ser únicas (UNIQUE) o cómo ordenar los registros si permitimos llaves duplicadas:
    • FIFO: Primero en entrar, primero en salir.
    • LIFO: Último en entrar, primero en salir.
    • FCFO: Primero en cambiar, primero en salir.
    • También usamos REF a este nivel para tomar las definiciones de campos de otro archivo (muy útil para estandarizar).
  2. Nivel de Formato de Registro: Nombramos el formato del registro. Podemos usar TEXT para documentar o FORMAT para copiar la estructura exacta de otro archivo existente.
  3. Nivel de Campo: Definimos el nombre, longitud, tipo de dato y descripciones (alias) de cada columna.
  4. Nivel de Campo Clave: Indicamos cuáles campos funcionarán como nuestra llave de acceso.

💻 Mis comandos del día a día

Para administrar estos archivos, hay un par de comandos que son vitales en la consola:

  • CRTPF (Create Physical File): Compila el archivo. Ojo: Si ya tienes datos y vuelves a compilar con este comando o la opción 14 en PDM, ¡perderás toda la información!
  • CHGPF (Change Physical File): Mi opción preferida si necesito recompilar un archivo modificado sin perder los datos, o para cambiar atributos como el mantenimiento de los accesos o tiempos de espera. Solo ten cuidado con los errores de Level Check si cambias la estructura y el atributo LVLCHK está activo (*YES).
  • CHGPFM (Change Physical File Member): Ideal para cambiar atributos a nivel de un miembro específico del archivo.
  • DSPFD y DSPFFD: Los comandos de consulta por excelencia. El primero te da la descripción general del archivo y el segundo te detalla la estructura campo por campo.

🚀 Modernización: Por qué ahora preferimos SQL

Aunque las DDS han sido nuestro estándar de batalla por décadas en IBM i, la realidad de nuestro desarrollo actual exige modernización.

Hoy en día, el estándar es utilizar SQL (DDL) para crear nuestras bases de datos. En lugar de escribir un código posicional y compilar con CRTPF, ahora creamos nuestras estructuras utilizando CREATE TABLE, CREATE INDEX y vistas.

¿Por qué el cambio?

  • Rendimiento: El motor avanzado de Db2 for i (SQE) está optimizado para consultas SQL.
  • Estandarización: Hablamos el mismo idioma que cualquier otro desarrollador de bases de datos, facilitando la integración con herramientas modernas.
  • Flexibilidad: Nos libramos de los límites rígidos de las DDS antiguas y ganamos validaciones nativas mucho más robustas.

Si vas a crear una estructura de datos nueva hoy, guarda las DDS en el cajón de la nostalgia y da el salto a SQL. ¡Tu yo del futuro te lo agradecerá!