Artículo: "Deploying Database Developments"

Existen numerosos mecanismos para llevar a cabo el despliegue de una base de datos. Partiendo de una necesidad concreta, los planteamientos que pueden adoptarse en el desarrollo de la base de datos van desde la improvisación, con los problemas que ocasionará posteriormente, hasta complicadas soluciones que aseguren el correcto funcionamiento del sistema en el escenario planteado y su futura escalabilidad, si procediese. Todo ello partiendo de que ese escenario impondrá en muchos casos cuál será el sistema de gestión de bases de datos a utilizar, ya que dependerá de numerosos factores, como la capacidad de la base de datos, si será distribuida o no, los tipos de acceso, etc.

En el artículo “Deploying Database Developments” de Alexander Karmanov se describe una metodología de implementación de las muchas existentes, que ayuda a comprender como llevar a cabo el despliegue de la base de datos de modo que se consiga un proyecto sostenible a medio y largo plazo.

Aunque existen herramientas que permiten comparar esquemas de desarrollo y sincronizar su funcionamiento, se hace hincapié en que estas abarcan soluciones generales que no tienen por qué adaptarse a un caso particular, y lo que es más importante, que más adelante debe ser la figura del administrador la que pueda decidir llevar a cabo un cambio en la base de datos conociendo perfectamente los pros y contras de ese cambio. El éxito de esta operación estará ligado entonces al modelo de desarrollo utilizado por el administrador, y con ello, al uso de un modelo consistente, comprensible y coherente con posibles actualizaciones del sistema. Aunque el artículo se refiere a una base de datos de SQL Server, utilizando T-SQL y herramientas vinculadas a esta aplicación, los conceptos que pueden extraerse de él podrían extrapolarse a cualquier otro sistema de gestión.

En el artículo se diferencian dos clases de “despliegue” del sistema, uno orientado a una implementación completa del mismo y otro hacia un despliegue incremental, más orientado a actualizaciones y cambios que puedan llevarse a cabo sobre una base de datos ya existente.

Se recalca en todo momento la importancia de registrar las variaciones que puedan realizarse, poniendo especial interés en identificar a la base de datos con un número de “actualización”, algo así como un control de versiones que indexe los cambios y los identifique para disponer de ellos para posibles necesidades futuras (de modo que esta operación sea lo menos tediosa posible). En este proceso de registro recomienda la utilización de hasta cuatro ramas en los archivos de configuración que abarquen aspectos comunes en la implementación de cambios: en primer lugar un archivo que se refiera a la estructura troncal del sistema de modo que a partir de él se definan las estructuras necesarias para ejecutar instancias de SQL Server conocidas, luego otros dos archivos referidos a los scripts necesarios para inicialización de la base de datos (creación de objetos e inserción de los datos iniciales), y un último que que especifique usuarios y permisos del sistema.

Otro aspecto interesante mencionado en el artículo se refiere a la separación lógica del código fuente según su función. En primer lugar está el código referido al esquema de la base de datos, todos aquellos elementos en los que realizar cambios afecta directamente a los datos almacenados. Después están aquellas funciones definidas por el usuario para el acceso a los datos, sin que cambios en ellas supongan una modificación de los datos en sí, y aquellos scripts que permiten insertar datos de modo automático por ejemplo para inicializar las tablas. Por otro lado estará la información relativa a los grupos de ficheros necesarios en la creación de la base de datos, ligado directamente con el esquema planteado inicialmente. También se especifica otro grupo lógico para aquellas descripciones de las políticas de acceso y de permisos, y en última instancia otro grupo para los aspectos relativos a los cambios en el sistema que permitan realizar transiciones entre estados pasados. A partir de esta clasificación, se definen una serie de esquemas en la estructura de operación del desarrollo del sistema, de modo que quede clara la arquitectura de almacenamiento para actuar sobre ella con garantías.

Se hace especial referencia a la necesidad de hacer uso de scripts para llevar a cabo modificaciones que afecten a distintos elementos de la base de datos y sobre todo para cargar datos en ella. En este punto pueden entrar a escena algunas herramientas ETL (Extract, Transform and Load) como SSIS (SQL Server Integration Services) para asegurar procesos de sincronización entre múltiples instancias de una base de datos u otras acciones que faciliten la labor del administrador.

El artículo incluye un ejemplo de creación de una base de datos muy interesante que permite ver aquellos puntos tratados de forma práctica.

Este artículo resulta importante para conocer ciertos puntos de partida a la hora de desarrollar una base de datos, recalcando la organización y el control sobre su estructura y sobre todos los cambios o actualizaciones que puedan llevarse a cabo. Dichas modificaciones responderán a variaciones en las necesidades del sistema, sin olvidar que estas harán que deban cambiarse funciones de acceso, scripts y demás componentes de administración y/o control. En última instancia estas medidas repercuten en tres aspectos fundamentales que están directamente ligadas al rendimiento de una empresa: eficiencia, escalabilidad y seguridad.