El modelado de datos es una técnica independiente de la implementación a la base de datos. Esto es importante, porque la metodología L5, siempre busca que se saque el máximo provecho de diversas herramientas. En particular, el esquema final y su implementación pueden sufrir cambios sin afectar de manera drástica la Lógica de Programación.

Uno de los puntos importantes que se deben indicar es que el modelado de los datos, debe ser llevado como una guía general. Para los profesionales expertos, esto implica el desarrollo de los Diagramas de Entidades y del Modelo Entidad-Relación. Independientemente de la metodología a utilizar, esta herramienta siempre será importante, para entender las relaciones entre las diversas entidades en la Base de Datos.

Cómo definir el esquema de la Base de Datos

Cuando definimos el Esquema de la Base de Datos estamos implementando en el lenguaje SQL del SGBD, el esquema de Modelado de Datos, anteriormente mencionado. Es preciso notar que se define “en el lenguaje SQL del SGBD”, este punto es importante que sea ampliado. Todos los SGBD, tienen diferencias finales en cuanto a la sintaxis que se maneja.

Sabemos que SQL es uno solo y que por eso es estándar, pero las diferentes distribuciones lo han implementado con ciertas variaciones. Están variaciones, son una de las causas en que el modelo de desarrollo, ha separado el Modelado de los Datos, con la Lógica de Programación.

El esquema de la Base de Datos, debe a mi parecer ser definido en el lenguaje SQL de nuestro Sistema Gestor de Base de Datos. La razón es básicamente sencilla: es más portable. Si lo hiciésemos en una aplicación nativa para un sistema operativo en especial y tratáramos de implementarlo directamente en otro sistema, podríamos llegar a tener complicaciones.

Es importante destacar, que no se trata de realizar todas las instrucciones SQL, en herramientas como Bloc de Notas. Muchas herramientas que podamos utilizar, nos permitirán exportar nuestra implementación a un archivo, que contendrá la sintaxis SQL. Además, si que sería destacable que como Administradores Generales de la Base de Datos, conociésemos de la sintaxis misma del lenguaje.

No es imperante que seamos unos gurus de la plataforma, pero siempre es importante que conozcamos los fundamentos. Muchas de las funciones que al final implementemos, serán producto de nuestra investigación personal a través de foros donde se mencionen las soluciones a los diversos problemas o funciones nuevas que podamos utilizar.

Herramientas que simplifican el trabajo

Al final, si utilizamos una herramienta que nos simplifique el proceso de implementación, siempre será importante guardar un archivo, con las sentencias SQL generadas por la misma. De hecho, con cada modificación debemos guardar una copia de respaldo.

Herramientas web como PHPMyAdmin, son muy importantes. La implementación y las pruebas generalmente las realizaremos en un computador local y vía interfaz web, podremos hacer el cambio desde el mismo Servidor instantáneamente y transparente al usuario.

Por qué optimizar

Creo firmemente que la labor como desarrolladores es que los productos, superen las expectativas de nuestros clientes. La optimización de la base de datos no escapa al proceso de optimización.

Un mal proceso de optimización a la Base de Datos, generará que el sistema sea inestable, poco fiable, con posibilidad de la información duplicada, lento para las transacciones, etc. Ahora bien, en el Modelo de Desarrollo la razón por la cual es necesario optimizar, es por que el modelo ve que cada aplicación no está exenta a ser actualizada.

Las aplicaciones, entornos de desarrollo y tecnologías van cambiando considerablemente. No podemos pretender que nuestro proyecto, siga funcionando por la eternidad en la versión del sistema en la que lo dejamos. El hacer tal cosa, solamente demostrará una mala calidad de trabajo y poca visión sobre el futuro de nuestra aplicación.

Los SGBD no cambian tan vertiginosamente, como otras tecnologías. Por lo cual, optimizar nos permitirá hacer un sistema adaptable, que utilice lo mejor del sistema y que pueda escalar sin problemas, dentro de un corto plazo, cuando veamos que la nueva versión, cumple y sobrepasa nuestras espectativas. Debemos siempre estar abiertos al cambio, pero utilizar lo mejor que haya en el momento presente.

En concepto de desarrollo escalado como cambiar de tecnología de BD sin alterar el modelo. Hasta este momento, muchos lectores preguntarán, por qué hacer tanto énfasis en cambiar de tecnologías. Uno de los motivos es la escalabilidad.

La importancia de la demanda

Dentro de los SGBD, existen muchas soluciones que nos brindan diferentes capacidades y características. Es muy común en la actualidad que los entornos de trabajo, se desarrollen para cumplir con metas a corto plazo y a medida que la aplicación, su entorno de trabajo y sus usuarios va en aumento; la aplicación debe responder a esas demandas, brindando mayor soporte a una mayor demanda de servicios.

Ahora bien, es probable que ante esta demanda de nuevos servicios, nuestro SGBD actual se quede corto en prestaciones y debamos mudar a otro gestor, sea por un mejor rendimiento a mayores transacciones, más requerimientos de seguridad, cambio de hardware y proveedor de software, etc.

Una aplicación, atada por completo a una sola plataforma, está condenada a desaparecer junto con la misma. Como desarrolladores, debemos ser previsores de tales acontecimientos, haciendo sistemas escalables.

Cuando separamos el modelado de Datos, estamos relegando al SGBD de turno, las operaciones de manipulación, control y actualización de los datos. Todos los sistemas actuales, ofrecen capacidades de programación de vistas, funciones, procedimientos y los tan famosos triggers.

Es importante que si utilizamos un sistema de desarrollo de este tipo, pensemos siempre en la generalización de su uso. La lógica de programación depende del modelado de Datos. Al centralizar las operaciones de mantenimiento de la información en el SGBD, y separar las funciones especiales que solo puede realizar el lenguaje, estamos independizando la Base de Datos del lenguaje de Scripting.

Si cambiamos de plataforma, y conservamos nuestro SGBD, la aplicación seguirá funcionando de la misma manera. Sea que cambiemos de lenguaje de programación, que utilicemos varios al mismo tiempo o que migremos a la versión posterior, siempre el modelo se mantendrá intacto.

Sería una práctica interesante, la de separar en un archivo en formato XML o de otro tipo, las diferentes consultas que generamos a la base de datos. A si, el lenguaje podría ir a leerlas. Así separamos y centralizamos aún más. Está practica sería de mayor importancia si combinamos tecnologías. Un esquema podría ser: 

 
<?xml version = "1.0" ?>
<database engine = "mysql" version = "5.0">
      <section type = "views">
            <view id = "72A35SRT"> SELECT * FROM `_employees`</view>
            <view id = "ERT56QS8"> SELECT `email` FROM `_clients`</view>
      </section>
      <section type = "functions">
            <function id = "8954DAER" success = "7946">
                  SELECT `user_exists`('%username%')
            </function>
      </section>
</database>

Centramos en un archivo todos los Queries, identificándolos con un ID. Esto podría conllevar un mayor procesamiento para el servidor, pero si optimizamos correctamente, podríamos llegar a mejor la respuesta, con un sistema de cache interno. El archivo podría ser accedido por cualquier script, debemos tener un cuidado especial para evitar la irrupción de terceros.

Manejo y optimización del almacenamiento y las funciones de gestión del contenido

Consideremos un ejemplo sencillo: imaginemos que estamos desarrollando una aplicación y que un procedimiento se debe realizar en varias partes de nuestro código. Que sería lo más conveniente a realizar: copiar una y otra vez el bloque de instrucciones o crear una sola función o procedimiento.

Esta misma situación ocurre, cuando programamos y ejecutamos consultas a la Base de Datos. Es increíble como nuestro código empieza a crecer en ambas direcciones de nuestro editor. Además, no solamente debemos fijarnos en ese aspecto.

Al mandar consultas desde el lenguaje de Scripting a la Base de Datos, el SGBD, debe interpretarla y ejecutarla. Obviamente, esto lo hace en milésimas de segundos. Pero, cuando hablamos de alrededor de mil consultas o más por segundo, el tiempo que se tarda por cada transacción es vital.

¿Cómo podemos solucionar este inconveniente y hacer que nuestra base de datos responda en un mejor tiempo?

La respuesta es utilizar procedimientos, funciones y vistas. Al estar dentro de la base de datos, estos suelen ser más rápidos, por que el SGBD, lo ha interpretado, depurado y optimizado con anterioridad, lo cual hace que las consultas sean más rápidas. 

La consulta general es: 
INSERT INTO `lands`(`land_id`, `landname`, `area`, `lang`)
            VALUES ("gt", "Guatemala", "108880", "es"); 

Y cambiaría a: 

SELECT `addland`("gt", "Guatemala", "108880", "es") 
<--

En lugar de mandar un query de inserción a una base de datos desde el script, es más sencillo, mandar los parámetros a la función almacenada en el SGBD. Dentro de la función está la consulta ya compilado.

Además, al centralizar las consultas, cualquier cambio hecho, alterará a todos los procedimientos del lado del script que lo utilicen. Esto ahorrará tiempo de desarrollo y mejorará el mantenimiento de la aplicación en su totalidad.

Conclusiones

Una buena separación de los componentes permitirá que nos enfoquemos en cada área de manera adecuada. Cuando tengamos que dar mantenimiento, iremos al punto exacto de la aplicación. Una buena estructura, generará mejores resultados y mayor rendimiento.

En el próximo artículo, veremos como debemos implementar la parte de programación. Aprenderemos más acerca de la optimización de la aplicación y comentaremos acerca de como se vincularía la tecnología del servidor, con la tecnología del explorador.

Descargar el ejemplo.

Lecturas relacionadas:

Juan Manuel Lemus
Juan Manuel Lemus

Editor del blog DotPress. Creador de la metodología de desarrollo L5 y jefe del proyecto Apperture Web Framework.

http://dotpress.wordpress.com