MS MySQL, MySQL y PostgreSQL pdf

lin

ux

@

so

ftw

ar

e.

co

m

.p

l

Microsoft SQL Server,

MySQL y PostgreSQL

La elección de un gestor de bases de datos en una empresa no es algo ni mucho menos trivial. De

partida, puede llegar a ser una inversión tanto en hardware como en software muy cuantiosa, pero

no sólo eso, además va a condicionar de manera determinante los desarrollos de aplicaciones que

tengan que interactuar con el mismo. Un SGBD, o Sistema Gestor de Bases de Datos crea un entorno

operativo que depende directamente de sus características, y en la mayoría de los casos, se convierte

en el centro del entramado informático de la empresa.

Santiago Gómez Ruiz

D

en inglés) es una plataforma de software que almacena los datos que se le introduz-can, debiendo garantizar principalmente su disponibilidad, su seguridad y su integridad. Esto significa que es un conjunto de programas que permiten el almace-namiento de información, velando porque se pueda dispo-ner de ella en cualquier momento, que la información sea correcta desde un punto de vista lógico y que sólo pueda ser accedida por las personas adecuadas.

Y de un modo más directo, el SGBD es el guardián de los datos de la empresa. Ni más ni menos. De ahí que sea trascendental su correcta elección.

Los productos que se analizan a continuación están creados en torno a un estándar en lenguajes de bases de da-tos, el SQL (Structured Query Language), proveniente del SE-QUEL (Structured English QUEry Language). Este último fue desarrollado durante la década de los 70 e implementado experimentalmente, ya que las máquinas comerciales de la época no tenían la suficiente potencia de cálculo como para ejecutar con rendimiento aceptable las operaciones del len-guaje. El lenguaje SQL se divide en tres sublenguajes:

• Lenguaje de definición de datos (DDL), que permite crear y alterar las estructuras en las que la informa-ción se almacena;

• Lenguaje de manipulación de datos (DML), que per-mite insertar, modificar, consultar y eliminar conteni-dos de la base de datos;

• Lenguaje de control de datos (DCL), que gestiona el acceso a los datos desde el punto de vista de la segu-ridad (usuarios), como desde el punto de vista de la integridad (concurrencia).

En este artículo se revisarán tres gestores: Microsoft SQL Server, MySQL y PostgreSQL. Los dos últimos son mul-tiplataforma, se encuentran implementaciones para varios

Santiago Gómez Ruiz es Director de Proyectos de Pro-talia, una consultoría española especializada en implan-tación y migración de Software Libre en entornos em-presariales, docentes e institucionales.

sistemas operativos, incluyendo GNU/Linux y Windows. Por el contrario, Microsoft SQL Server sólo funciona sobre Windows. Nuestra instalación será modesta, 25 puestos de tra-bajo.

Se parte de la premisa de que se trata de una nueva instalación, sin ningún producto anterior instalado y por lo tanto, sin gastos de migración, que serían muy variables. La segunda parte de este artículo trata de cómo sería un proceso de migración.

El que se evalúen estos tres SGBD no sig-nifica que sean los únicos o necesariamente los mejores para un propósito determinado. Hay productos magníficos como Oracle y DB2, am-bos cerrados y de un precio considerablemente alto. Lamentablemente, todos los SGBD del mercado no caben en este artículo.

Esto es importante, porque independien-temente de las características propias de cada SGBD, éste a su vez va a correr sobre un sis-tema operativo, beneficiándose de sus puntos fuertes y viéndose perjudicado por sus debili-dades. Por muy potente que sea un determi-nado aplicativo, si se implementa sobre un sistema operativo pobre, el resultado no puede ser excepcionalmente bueno.

Por lo tanto, el primer extremo a consi-derar será el sistema operativo a elegir para hospedar a nuestro SGBD. Consideraremos GNU/Linux Debian 3.1 Sarge por una parte, y Microsoft Windows 2003 Server STD por otra.

Microsoft Windows 2003 Server (www. microsoft.com/spain/windowsserver2003/default. mspx) es probablemente el sistema operativo más estable y seguro de Microsoft. Lamentable-mente, eso no es mucho. Tanto en estabilidad como en seguridad deja mucho que desear, de hecho, la puesta en producción de una máquina con Windows nos va a obligar a la adquisición de un software antivirus.

En cuanto a la estabilidad, un problema endémico de todos los sistemas operativos de Microsoft son sus bajas tasas de disponibili-dad. Esto se debe fundamentalmente a dos motivos:

• Los sistemas se quedan colgados con una facilidad alarmante. Cada cuelgue y su posterior reinicio significan que se ha per-dido tiempo, pero que además es posible que se haya perdido trabajo sin consoli-dar en los archivos. En un contexto de ba-ses de datos, esto puede causar graves in-consistencias. El hecho de que cualquier alteración mínima en el hardware, hasta a veces en el más periférico (por ejemplo, simplemente al insertar un pendrive,

si-tuación que he experimentado yo perso-nalmente), exija un reinicio del sistema no ayuda a mejorar la disponibilidad; • Los tiempos de mantenimiento son

eleva-dísimos, en parte causados por el defi-ciente sistema de ficheros utilizado, NTFS, que obliga a defragmentar los sistemas de archivo muy frecuentemente. Casi ca-da actualización del sistema operativo obliga a reiniciar el sistema.

En cuanto a la seguridad, y aún con un buen antivirus actualizado, nada puede detener a un virus lo suficientemente reciente como para no constar en las bases de datos de nues-tro antivirus. La cantidad de vulnerabilidades gravísimas que han afectado a los sistemas operativos de Microsoft, y que en alguna oca-sión, como con los virus Sasser y Blaster, han llenado telediarios, no animan a confiar en la seguridad del sistema.

En cuanto al rendimiento, es más pobre que el resto de los sistemas operativos. Si a es-to le añadimos la muy intensa carga de tra-bajo del antivirus y la imposibilidad de des-activar la sesión gráfica, que es una auténtica devoradora de recursos, el rendimiento se ve muy seriamente mermado.

En consecuencia, y por si todo lo anterior fuese poco, Microsoft Windows 2003 Server es muy exigente en cuanto a hardware.

Finalmente, habría que hacer una consi-deración final sobre este sistema operativo de código cerrado: ¿es prudente confiar todos los datos de nuestra empresa a un sistema operativo que sólo Microsoft sabe lo que hace

por debajo de la interfaz gráfica? Esto es una cuestión subjetiva, y cada administrador de-berá valorar su peso en la decisión.

El precio de Microsoft Windows 2003 Server STD es de 490,24 € , más 4 paquetes de 5 licencias para uso de los puestos de traba-jo: 457,36 * 4 = 1.829,44 €, sumando un total de 2319,68 euros.

En cuanto al sistema operativo GNU/Li-nux Debian 3.1 Sarge, es un sistema operativo de código abierto, y totalmente libre y gra-tuito, que se puede descargar de la página principal del proyecto (http://www.debian.org) o desde cualquiera de sus mirrors.

La estabilidad de Debian es legendaria. Salvo errores de hardware y lógicamente apa-gones, la probabilidad de tener que reiniciar un servidor basado en Debian es remotísima. La modularidad propia del sistema permite actualizarlo sin tener que reiniciar, ya que el mismo actualizador detiene el servicio que sea necesario, lo actualiza y vuelve a iniciarlo, en apenas un segundo.

La seguridad de Debian es la propia de la mayoría de las distribuciones de GNU/Li-nux, salvo casos exóticos como Linspire. Po-líticas conservadoras de seguridad, perfecta delimitación de los usos del administrador y el usuario y perfecta compartimentación de los directorios que cada uno puede utilizar y su grado de utilización permiten al admi-nistrador de un servidor basado en Linux dormir tranquilo por las noches.

Los virus no son un problema en Linux. Salvo experimentos en laboratorio, en los que expresamente se abren vulnerabilidades en el

sistema, y posteriormente se aprovechan, o in-cluso extravagancias como emular un virus de Windows con privilegios de administra-dor. En conclusión, incluso provocándolo expresamente, es muy difícil hacer funcionar un virus para Linux.

Vaya, que si lo que queremos es fastidiar nuestra máquina, es más fácil meterle fuego.

Una ventaja común a todas las distribucio-nes de GNU/Linux es que son altamente per-sonalizables. Esto significa que se puede des-cargar al sistema de todo lo que no se necesi-ta, incluyendo el sistema gráfico, dejando so-lamente las funcionalidades que se van a uti-lizar. Lo anterior redunda en que el sistema sea más liviano y más rápido, resumiendo, aumenta el rendimiento.

De hecho, la interfaz gráfica se puede dejar desactivada, o se pueden instalar interfaces gráficas sencillas e increíblemente ligeras,

co-mo Fluxbox, Xfce o Enlightenment, que apenas

impactan en los recursos. Yo personalmente suelo dejarla desactivada, y sólo la utilizo por comodidad en algunos casos, ya que realmen-te, ¿para qué necesita un servidor la interfaz gráfica la mayoría de su tiempo?

Como se ha comentado, la licencia de GNU/Linux Debian 3.1 Sarge es gratuita y su descarga libre: precio 0€.

A estas alturas, la comparativa perjudica a Microsoft SQL Server, ya que únicamente puede ejecutarse sobre Windows.

Microsoft SQL Server (

https://www.micro-soft.com/latam/sql/) en sí es un buen producto,

probablemente de los mejor acabados por Mi-crosoft. Su instalación es sencillísima, su

inter-faz es clara e intuitiva y viene acompañado de una suite de utilidades bastante completa.

La herramienta de administración de Microsoft SQL Server (Microsoft SQL Server

Enterprise Manager) muestra la habitual

dis-posición de este tipo de aplicativos de Micro-soft, esto es, un árbol a la izquierda donde se muestra cada objeto clasificado por su tipo, y un panel a la derecha donde se modifican las propiedades de dicho objeto. Esta dis-posición permite acceder fácilmente a cual-quier objeto de la base de datos, detener y re-iniciar el servicio y utilizar las utilidades in-cluidas.

Dentro de estas utilidades, aparte de bas-tante detallados programas de mantenimien-to, podemos encontrar importadores/expor-tadores de datos y demás herramientas acce-sorias al propio SGBD.

Microsoft SQL Server posee disparadores

(triggers). Los disparadores son

procedimien-tos que se ejecutan cuando ocurre un evento determinado, por ejemplo, que se inserte, mo-difique o elimine un registro. De esta manera, parte de la lógica de la aplicación la realiza la base de datos.

La utilización de disparadores es muy conveniente tanto por rendimiento como por mantenibilidad de las aplicaciones cliente. Por rendimiento, porque el proceso se ejecuta en el mismo servidor, evitando el trasiego de consultas SQL y datos entre cliente y servi-dor. Por mantenibilidad porque de esta for-ma, esta lógica es independiente de la aplica-ción, lo que asegura que la implementación de la lógica no se vea alterada por diferentes

clientes de la base de datos, o por fallos de programación en los mismos clientes.

Otra característica incluida en Microsoft SQL Server son los procedimientos almace-nados (stored procedures). Estos procesos se ejecutan a petición de las aplicaciones cliente y tienen que estar escritos en lenguajes com-prensibles por el motor de base de datos, por ejemplo, y tratándose de Microsoft SQL Ser-ver, se podrían escribir en .NET.

Las ventajas de los procedimientos al-macenados son las mismas que las de los dis-paradores: rendimiento y mantenibilidad. Un uso eficaz de ambos elementos permite la creación de clientes de la base de datos lige-ros, fáciles de depurar y de escribir y libres de errores. Operaciones tediosas y propensas a pequeños errores, como las validaciones de campo, se pueden implementar en base a dis-paradores, y otras operaciones complejas co-mo ajustes de stock en una facturación se pro-gramarán una sola vez, garantizando su va-lidez independientemente del cliente utiliza-do.

Si bien la interfaz de usuario es muy bue-na y sobre el papel tiene muchas funciobue-nali- funcionali-dades, Microsoft SQL Server adolece también de serios problemas. Las pruebas de rendi-miento nunca son definitivas, los escenarios de ejecución son tan variopintos que cual-quier productor de un SGBD puede acondi-cionar la prueba a un escenario propicio a su producto. Eso es posible hasta con Microsoft SQL Server, el producto de los tres evaluados con peor rendimiento en general, según la experiencia común de los administradores. Aunque se puedan encontrar estudios sufra-gados por Microsoft que demuestran que en un determinado ambiente ejecutando una determinada consulta con un hardware muy concreto Microsoft SQL Server puede superar a sus competidores en cuanto a rendimiento, la regla general es que es el SGBD más lento para la gran mayoría de las tareas. El hecho de que sólo pueda ejecutarse en el sistema operativo más pobre en rendimiento de los dos considerados tampoco ayuda.

Otro aspecto que no favorece a Microsoft SQL Server es la estabilidad. Sus tablas tien-den a corromperse fácilmente, permitiendo la duplicación de claves únicas y desastres de ese tipo. Es importante incluir una recons-trucción de tablas en el programa de manteni-miento diario de la base de datos para evitar su degeneración.

De manera similar a Microsoft 2003 Ser-ver, Microsoft SQL Server funciona en un sistema de licencias en el cual se paga por el servidor, y luego por cada puesto que se sirve

de él. En nuestro caso, el precio por imple-mentar nuestra solución de base de datos con Microsoft SQL Server con 25 clientes sería de 6.411,90€. Además, hay que tener en cuenta que al funcionar solamente sobre el sistema operativo de Microsoft, habría que añadir el importe de la licencia del servidor y los clien-tes, con lo que el precio final, sólo en licencias, sería de 8.731,58€ (no es un error tipográfico).

MySQL AB (www.mysql.com/) es una em-presa sueca que lleva desde 1995 desarrollan-do el SGBD homónimo. El My que antecede al nombre de todos los productos de esta compañía coincide con el nombre de la hija de uno de los fundadores, MontyWidenius, lo que ha llevado a pensar que es el origen del nombre de los productos.

El servidor de bases de datos MySQL es de código abierto. Se distribuye en dos ver-siones, una comercial, de pago y que incluye soporte, y otra gratuita, basada en el soporte de la comunidad. Hay que decir que este so-porte comunitario es extensísimo.

Este producto parece orientado a las ne-cesidades de una organización media. Du-rante mucho tiempo, un argumento muy es-crito en los foros que tratan el tema es si lo que quieres es velocidad, usa MySQL, si lo que

quieres son funcionalidades, usa PostgreSQL. Eso

hoy en día no es tan cierto. Si bien MySQL ha destacado por su velocidad en operaciones de lectura (no tanto en escritura) y se le han echado en falta funcionalidades, la versión 5 (actualmente la versión en producción) del SGBD incuye muchas de estas funcionalida-des, incluyendo disparadores y procedimien-tos almacenados. Por otra parte, la optimiza-ción de PostgreSQL en cuanto a velocidad los ha dejado muy cerca, de hecho, en entornos multiprocesador, PostgreSQL escala mucho mejor que MySQL.

Uno de los puntos fuertes de MySQL es su facilidad de uso y la documentación existente. Está tan extendido, que gran can-tidad de plataformas web están construidas contando con MySQL. Estas son las llamadas plataformas LAMP (Linux+Apache+MySQL +PHP), que utilizan Linux como sistema ope-rativo, Apache como servidor web, MySQL como base de datos y PHP como lenguaje de las páginas.

Muchos de los gestores de contenidos que se utilizan hoy en día están basados en este modelo, como PHPNuke, Drupal, Post-Nuke, Joomla! y Mambo, y aunque desconoz-co las cifras, la desconoz-combinación de estos gestores agrupará a una mayoría abrumadora de ges-tores de contenido actualmente en línea. Este hecho demuestra la fiabilidad y rapidez del

lenguaje y su aptitud para tareas de este tipo, es decir, muchas lecturas simultáneas, pocas escrituras proporcionalmente, y accesos más bien simples a los datos. En estos entornos, MySQL simplemente no tiene rival hoy en día.

Además de un potente interfaz en modo consola, MySQL cuenta con diversas herra-mientas de administración, siendo tres los más populares: MySQL Administrator (desa-rrollado por la misma empresa), phpMyAd-min (www.phpmyadmin.net) y el módulo de administración de MySQL para Webmin.

MySQL Administrator es una utilidad muy completa que permite la administración de las bases de datos instaladas en el sistema. Puede conectarse a cualquier servidor, con las lógicas medidas de seguridad. De un modo gráfico permite crear y modificar bases de datos, tablas, relaciones, usuarios, programar tareas de mantenimiento, copias de seguri-dad, sincronizar varios servidores, ajustar los parámetros del servidor, etc. Es decir, que tie-ne poco que envidiar a Microsoft SQL Server Enterprise Manager.

Webmin (www.webmin.com) es una plata-forma web de administración de equipos muy popular entre administradores, ya que con un navegador se tiene un interfaz unificado para controlar cada aspecto de un servidor, inclu-yendo instalación y desinstalación de hard-ware, administración de discos y particiones, de servicios, usuarios y casi cada cosa que se pueda imaginar. Webmin es una herramienta deliciosa para cualquier administrador. El

mó-dulo de MySQL para Webmin permite el con-trol detallado del gestor de bases de datos des-de cualquier parte des-del mundo con un simple navegador, sin depender de ningún software ni ningún sistema operativo específico.

PhpMyAdmin es otra herramienta de ad-ministración web de MySQL de mucho éxito. Es más completa y aún más fácil de usar que el correspondiente módulo de Webmin. Su

desventaja se podría considerar que no está

integrada en Webmin, junto al resto de las utilidades de administración del sistema, su principal ventaja respecto a este último es que es un interfaz totalmente pensado para MyS-QL y por lo tanto, mejor adaptado y potente.

MySQL es un SGBD altamente configura-ble es sus parámetros físicos, ya que permite elegir el tipo de tabla para cada una de las que componen la base de datos, desde tablas orientadas a la lectura rápida y alojadas ente-ramente en RAM, hasta diferentes tipos de es-tructura de organización de ficheros. Del mis-mo mis-modo, parámetros muy internos comis-mo el tamaño y uso de los búferes y la organización de la memoria están accesibles al administra-dor. De esta forma, un administrador puede constantemente ir ajustando el rendimiento de las bases de datos tabla a tabla, conforme el volumen de los datos va evolucionando. Con un administrador cuidadoso, se pueden alcanzar grandes rendimientos.

MySQL es multiplataforma, se puede ins-talar igualmente sobre Windows que sobre GNU/Linux. De hecho, según la wikipedia,

MySQL funciona sobre múltiples plataformas,

incluyendo AIX, BSD, FreeBSD, HP-UX, GNU/ Linux, Mac OS X, NetBSD, Novell Netware, OpenBSD, OS/2 Warp, QNX, SGI IRIX, Sola-ris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Vista y otras versiones de Windows. También existe

MySQL para OpenVMS. Si fuese necesario un

ejemplo de lo que es multiplataforma, sería difícil encontrar uno mejor.

Como se ha comentado antes, MySQL se puede descargar libremente desde la web del fabricante, bien como código fuente, bien en forma de binarios. Además, la gran mayoría de las distribuciones de Linux incorporan en sus repositorios los paquetes precompilados y configurados para instalarse sobre la mar-cha limpiamente. Para Windows, sólo hay que descargarse el instalador de la página de MySQL AB.

La versión con soporte oscila en precio entre los 595$ y 4995$, dependiendo del nivel de soporte ofrecido por la empresa creadora del producto. Se puede obtener soporte de otras muchas empresas a precios muy dife-rentes.

El soporte para cada uno de estos pro-ductos requiere una cualificación muy pare-cida, ya que tanto conceptualmente como en sus interfaces son muy parecidos y la curva de aprendizaje es mínima. Por lo tanto, no se tienen en cuenta los gastos de administración y mantenimiento, que serían prácticamente los mismos.

Precio de MySQL 0 €

PostgreSQL (www.postgresql.org/) es un SG-BD que hunde sus raíces en los desarrollos de la Universidad de Berkeley, como tantas otras magníficas creaciones de software. El proyecto nace con el nombre de Ingres, y tras una primera descontinuación por parte de su creador, Michael Stonebraker, el proyec-to se reproyec-toma como un proyecproyec-to post-Ingres. El resultado es llamado entonces Postgres. Tras unos años de desarrollo en el seno de la Universidad, el proyecto se estabiliza y se abandona por parte de ésta. En ese momento (1993), y gracias a su licencia libre, se retoma por la comunidad convirtiéndose ya en Post-greSQL.

Por lo tanto, a diferencia de los dos ante-riores, no hay una compañía tras el producto, es creado y mantenido exclusivamente por la comunidad. Eso no quiere decir que no haya soporte comercial, en la misma página del proyecto se puede acceder a multitud de empresas que ofrecen soporte de pago para el producto.

Desde siempre, PostgreSQL ha estado arropado por la fama de ser un producto muy profesional, completo y serio, aunque no ex-cesivamente rápido comparado con MySQL. Como expuse antes, eso ya no es cierto. Post-greSQL es tremendamente eficiente, sobre todo en entornos multiprocesador y MySQL se le ha acercado mucho en funcionalidades.

Si MySQL ha ocupado el nicho de las ap-licaciones web y aquellas con un moderado tamaño, PostgreSQL es la elección tradicional para aplicaciones serias, de la dimensión de ser-vidores de dominios raíz de DNS, y de em-presas con volúmenes realmente grandes de datos. De todas formas, cada vez este uso viene siendo determinado más por la tradición y las herramientas existentes que han surgido al-rededor de este tipo de proyectos que por la imposibilidad de usar MySQL en un proyecto realmente grande, o una excesiva complejidad de PostgreSQL.

Porque la desventaja clásica que se aduce al hablar de PostgreSQL es la complejidad, al ser más grande es más complicado. Realmente no tiene por qué ser así. Además del clásico interfaz de consola, existen utilidades libres e igualmente multiplataforma para la adminis-tración de servidores PostgreSQL.

Tres ejemplos a considerar podrían ser pgAdmin III (www.pgadmin.org/), Pg Access

(www.pgaccess.org/) y phpPgAdmin (

http://php-pgadmin.sourceforge.net/). Las dos primeras

herra-mientas siguen el esquema del árbol de objetos a la izquierda y el panel de propiedades a la de-recha, y permiten la gestión de usuarios y gru-pos, uno de los temas complejos de Postgre-SQL. Son aplicaciones gráficas intuitivas a la altura de las correspondientes a los dos SGBD anteriormente evaluados. En cuanto a phpPg-Admin, es la contrapartida funcional a phpM-yAdmin, aunque manteniendo la estructura tí-pica de árbol a la izquierda y panel a la derecha, un producto muy profesional.

Además, también existe un módulo de Webmin para PostgreSQL, lo que aporta idénticas ventajas que su homólogo para My-SQL.

Al ser un producto abierto y gratuito, y al igual que con MySQL, también se pueden descargar de la página de PostgreSQL tanto fuentes como binarios y ejecutables para Win-dows. Por supuesto, también están disponi-bles paquetes preconfigurados en los repo-sitorios de las principales distribuciones de GNU/Linux.

Precio de PostgreSQL: 0 €

Los sistemas gestores de bases de datos son piezas de software tan complejas que los

aná-lisis anteriores son simples orientaciones. Pa-ra tener una idea más detallada de todas y cada una de las características que poseen y las que no poseen cada uno de estos tres productos, una buena idea es visitar esta com-parativa de la página de MySQL: http://dev.

mysql.com/tech-resources/features.html.

La comparativa, a pesar de estar alojada en la página de MySQL es más que razonable-mente objetiva, y podrá ayudar a determinar, basado en las necesidades concretas, el SGBD que mejor se ajuste a nuestras necesidades.

Otra historia es intentar encontrar una comparativa de rendimiento. Como ya expuse anteriormente, son infinitos los escenarios de desempeño posibles, y siempre habrá algún escenario que beneficie particularmente a un SGBD (consecuentemente, hay casi infinitas comparativas de rendimiento con casi infi-nitos resultados contradictorios). La opinión de quien sufra cada uno de estos productos puede orientar mucho más que cualquier ben-chmark.

Resumiendo, las conclusiones serían:

• Windows + Microsoft SQL Server: 8.731, 58€: Recomendable si por alguna razón el software a utilizar no puede funcionar con otra plataforma. Es muy caro, menos es-table, menos eficiente, menos seguro y no aporta nada fundamental que no aporte cualquier otra opción;

• Windows + MySQL/PostgreSQL: 2319, 68€: Si el gestor de bases de datos es libre y multiplataforma, la única razón para utilizar un sistema operativo propietario, caro e inestable es que sea necesario para cualquier otra cosa además de soportar la base de datos. Parece un poco absurdo a priori;

• GNU/Linux Debian 3.1 Sarge+ MySQL: 0€: Solución estable, gratuita, rápida y segu-ra. Muy recomendable para desarrollos medios, ya que hay mucha documenta-ción al respecto. Es conveniente revisar las funcionalidades necesarias para nues-tra aplicación, y verificar que todas son cu-biertas por MySQL. Especialmente indi-cado para aplicaciones web;

• GNU/Linux Debian 3.1 Sarge + Postgre-SQL: 0€: Marco ideal para desarrollos gran des y con un tratamiento de datos exten-sivo. La combinación es estable, gratuita, segura y muy potente.

produc-tos en el mercado, puesto que individualmen-te suelen ser poco recomendables.

Cambiar un SGBD por otro no es una tarea trivial. En primer lugar, hay que tener muy buenas razones para hacerlo. Las mi-graciones suelen ser de propietario a libre, y antes siquiera de proponer la migración, hay que tener claros ciertos conceptos. Es normal asumir el cargo de una instalación y encon-trarse con que la misma está implantada so-bre Windows. Eso en principio no es motivo suficiente para migrarla antes de hacer ciertas consideraciones:

• ¿Están mínimamente amortizadas las licencias? Si bien no es una considera-ción técnica, que el nuevo administrador proponga tirar a la basura una millonada en licencias casi por estrenar no es una buena forma de empezar a hacer amigos. Aunque consideraciones de rendimiento, disponibilidad y seguridad lo aconsejen, si la situación no es escandalosamente crítica, normalmente la empresa optará por aguantar un tiempo el sistema pro-pietario recién implantado que cambiar a uno libre.

• ¿Cuántas horas de trabajo efectivo se están perdiendo por utilizar un sistema operativo inseguro? Eso es un argumen-to muy pesado.

• ¿Qué riesgos de seguridad se están co-rriendo con una instalación de ese tipo? El peso de este argumento es proporcional a la confidencialidad o valor de los datos almacenados.

• ¿Qué coste va a tener la migración de los datos? Esta es la pregunta más difícil de responder.

Existen muchas herramientas de migración entre distintos SGBD. Sorprendentemente, Microsoft ha dotado a su SQL Server de una herramienta de exportación bastante buena que facilita la tarea, pero además se pueden utilizar distintas aplicaciones de migración gratuitas que aportan diferentes grados de

inteligencia al migrar. Pero aunque son útiles

en la migración de bases de datos sencillas, con tipos de datos poco complicados y poco relevantes en sí, no pueden sustituir el cono-cimiento del administrador sobre las caracte-rísticas de los datos que van a ser necesarias.

Porque migrar una base de datos no es co-piar unas tablas de un formato a otro. Es muy recomendable disponer de una instalación ralela con al menos un servidor y un cliente pa-ra estudiar la migpa-ración. En este labopa-ratorio, se documentarán todos los pasos hasta lograr la migración exitosa, de modo que al aplicarlo a la instalación real, los problemas sean mínimos o ninguno. En primer lugar, es muy conveniente estudiar los tipos de datos que soportan tanto el SGBD origen como el destino, y establecer un mapeo de tipos, tabla por tabla. Si es posible, generar las tablas vacías en el SGBD destino con los tipos de datos correctos para nuestra aplicación. Mucho ojo con los tipos de datos numéricos, de tipo fecha y booleanos, suelen dar sorpresas. También hay que estudiar el comportamiento de los valores nulos y autoin-crementales en ambos sistemas.

El siguiente paso es copiar los contenidos de las tablas desde el origen al destino. Este procedimiento en sí no debe ser complicado.

A continuación, se deben reproducir las re-laciones de forma que funcionen exactamente igual en el sistema de origen y el destino. De-finir correctamente los índices, y ajustar los pa-rámetros que afecten al rendimiento de cada tabla.

Finalmente, habrá que migrar los scripts, esto es, procedimientos almacenados y dispa-radores, verificando que uno a uno funcione y adaptando o reescribiendo el código.

Supuestamente en este punto ya debería de funcionar perfectamente, se conecta el cliente a la base de datos nueva y se prueban a fondo las funcionalidades de la aplicación. Para este paso es un factor de ayuda muy im-portante a efectos de depuración el contar con el código fuente de la aplicación cliente, de forma que se pueda controlar perfectamente qué estaba pidiendo la aplicación a la base de datos en el momento en que surgió el fallo. Es posible que haya que ajustar distintos pará-metros o incluso que modificar ligeramente el código de la aplicación cliente.

Si se verifica el correcto funcionamiento de la aplicación cliente, es el momento de pasar a la implementación en la instalación real. Por muy documentado y probado que esté el proceso, el mundo real está lleno de amargos sinsabores, lo que aconseja realizar la migración en fin de semana, o en el espacio de tiempo más largo de que se disponga entre los períodos de uso de la aplicación, y asegurarse siempre de que pode-mos dar marcha atrás y dejar la instalación tal como estaba mientras volvemos al laboratorio a investigar cual ha sido el fallo. Raramente se sobrepasan dos intentos hasta que el sistema funciona de forma fluida. No obstante, los pri-meros días de utilización, incluso con toda una batería de pruebas a las espaldas, hay que estar muy vigilante, intentando anticiparse a prob-lemas que puedan surgir, que es la mejor ma-nera de solucionarlos. Siendo cuidadosos y de-jando a un lado las prisas y los plazos se puede lograr una migración exitosa. Idealmente, los usuarios saldrán el viernes a disfrutar del fin de semana, y el lunes volverán al trabajo, y sólo notarán que su aplicación funciona más rápido y no se cuelga. La dirección de la empresa notará a corto plazo un aumento de la productividad y a medio plazo un descenso en los gastos deri-vados del mantenimiento informático.

Y el informático sentirá que ha hecho un buen trabajo, que ha optimizado costes, evi-tado riesgos a su empresa y facilievi-tado la vida a los usuarios. Y ese es un sentimiento de satis-facción difícilmente igualable.