Con toda probabilidad, la parte más crítica de un sistema de información es el
sistema de bases de datos empleado. Esto no tiene discusión. El problema es: es
un mundo ensangrentado por las guerras comerciales, ¿cómo confiar en la auto
recomendación de las maravillas de una base de datos hecha por el propio
fabricante?
Este artículo tiene un carácter más bien informativo y de ayuda para la toma
de decisiones. Si lo que necesita son más detalles técnicos puede
consultar el artículo Escogiendo
un servidor SQL, en mi página personal.
Claro que no existe, a pesar de las afirmaciones de fabricantes y
distribuidores. Hay sistemas de gestión de bases de datos mejores y peores.
Entre los buenos, cada uno destaca por alguna característica especial, y falla
en algo casi siempre sorprendente.
La cuestión, entonces, consistirá en elegir la base de datos que mejor se
adapte a las dimensiones del proyecto, principalmente al grado de concurrencia
y a las características físicas de la red sobre la que se implementará la
aplicación, y a nuestro presupuesto.
Esta presentación de productos se ocupará exclusivamente de sistemas
relacionales. Ya el propio hecho de ser relacional plantea algunas limitaciones
al producto. Sin embargo, aunque ya despuntan algunos sistemas de bases de
datos orientadas a objetos, la nueva tecnología no acaba de consolidarse por
diversas razones. La principal de ellas: la inercia de la industria y de la
comunidad de desarrolladores.
He aquí una de las bases de datos más conocidas y de mejor nombre. Y sí: se
trata de una opinión bien ganada. Oracle es potente y altamente eficiente.
La versión más reciente de Oracle es la 8 punto algo. Y es que desde el
lanzamiento original de la 8 se sucedieron varias versiones con correcciones,
hasta alcanzar la estabilidad en la 8.0.3. El motivo de tantos fallos fue, al
parecer, la remodelación del sistema de almacenamiento por causa de la
introducción de extensiones orientadas a objetos.
¿Qué hay de los objetos de Oracle? Este sistema ha comenzado a evolucionar
en esta dirección, añadiendo tipos de clases, referencias, tablas anidadas,
matrices y otras estructuras de datos complejas. Desafortunadamente, la
implementación actual de las mismas no ofrece una ventaja clara en eficiencial,
como sería de esperar, y sí provocan la incompatibilidad de los diseños que
aprovechan las nuevas características con otras bases de datos. Aunque Delphi y
C++ Builder soportan perfectamente las extensiones de objeto de Oracle, no soy
partidario de utilizarlas, al menos en el estado actual de la tecnología.
Oracle soporta todas las funciones que se esperan de un servidor
"serio": un lenguaje de diseño de bases de datos muy completo
(PL/SQL) que permite implementar diseños "activos", con triggers
y procedimientos almacenados, con una integridad referencial declarativa
bastante potente. Permite el uso de particiones para la mejora de la
eficiencia, de replicación e incluso ciertas versiones admiten la
administración de bases de datos distribuidas. El software del servidor puede ejecutarse
en multitud de sistemas operativos. Existe incluso una versión personal para
Windows 9x, lo cual es un punto a favor para los desarrolladores que se llevan
trabajo a casa.
El mayor inconveniente de Oracle es quizás su precio. Incluso las licencias
de Personal Oracle son excesivamente caras, en nuestra opinión. Otro problema
es la necesidad de ajustes. Un error frecuente consiste en pensar que basta
instalar el Oracle en un servidor y enchufar directamente las aplicaciones
clientes. Un Oracle mal configurado puede ser desesperantemente lento. También
es elevado el coste de la formación, y sólo últimamente han comenzado a
aparecer buenos libros sobre asuntos técnicos distintos de la simple
instalación y administración.
Es una lástima que un sistema tan bueno como InterBase no sea más popular de
lo que actualmente es. Y ya podemos mencionar el principal enemigo de
InterBase: la incertidumbre sobre su futuro. Esperemos que el nuevo sistema de
desarrollo y distribución no lo estropee.
InterBase destaca del resto de los sistemas de bases de datos por su
arquitectura única, basada en versiones. Esto quiere decir que, a pesar de
tratarse del sistema más barato, es también el que ofrece un mejor acceso
concurrente a los datos que administra. Si necesitamos una vista coherente de
la base de datos, Oracle, SQL Server y DB2 bloquean la información que leen e
impiden su actualización durante la duración de la transacción de lectura. Esto
no sucede en InterBase porque la escritura genera una nueva versión del
registro, sin perder la coherencia de la información. Una agradable
consecuencia es que podemos realizar copias de seguridad completas "en
caliente", sin interrumpir el funcionamiento del sistema.
Otro de los puntos fuertes de InterBase es su cercanía al estándar de SQL,
sobre todo en la sintaxis de procedimientos almacenados y triggers. Es
sumamente fácil programar una base de datos activa en InterBase y
posteriormente adaptar la definición para Oracle. El lenguaje de procedimientos
y triggers es muy potente, e incluso supera a Oracle en la facilidad para
expresar cláusulas de verificación check que involucren a
varias tablas, y en que los triggers no están sujetos a los problemas
ocasionados en Oracle por las denominadas "tablas mutantes".
La versión actual de InterBase es la 5.6 (escribo en mayo del 2000), pero ya
está todo preparado para el lanzamiento de la versión 6. Esta versión añade
tipos de datos nuevos compatibles con el estándar de SQL. Por ejemplo, ahora se
introducen tipos separados para la fecha, la hora y para la combinación de
ambas (Microsoft SQL Server sigue soportando solamente el último tipo), tipos
numéricos "exactos", etc. Pero quizás la mayor novedad sea la
aparición de un motor de replicación incluido con el producto, una carencia muy
señalada en las versiones anteriores.
Los problemas de InterBase se deben a la misma causa que sus ventajas: su
arquitectura única. Es muy sencillo realizar particiones en otros sistemas (Oracle,
DB2, SQL Server, Informix) para aumentar el rendimiento físico de una base de
datos, pero este concepto es difícil de adaptar para InterBase. De todos modos,
el particionamiento por software no es sino un sustituto un poco más flexible
de ciertas técnicas RAID para la mejora del rendimiento, e InterBase sí permite
que una base de datos se expanda a lo largo de varios discos, aunque no
controla qué tablas van a parar a qué dispositivo.
Para poder hablar de Microsoft SQL Server hay que dejar bien claro a qué
versión del producto estamos refiriéndonos. Porque las versiones 6.5 y
anteriores son un auténtico desastre, pero la versión 7 es un sistema a tener
en cuenta.
Los problemas de la 6.5 eran muchos: bloqueo a nivel de página, dispositivos
con crecimiento manual, un tamaño de página fijo y demasiado pequeño (2048KB),
una pésima implementación de los tipos de datos variables como varchar...
Todo esto ha sido resuelto en SQL Server 7: las páginas han aumentado a 8192KB
(aunque este tamaño sigue siendo constante), el bloqueo se produce a nivel de
fila, las columnas de tipo variable ocupan ahora lo justo y han desaparecido
los odiados dispositivos, abriendo paso a ficheros nativos del sistema
operativo con crecimiento automático.
El atractivo principal: la baratura del sistema, y la tendencia de los
directivos a aceptar preferentemente productos de Microsoft. Además, hay que
reconocer que la versión 7 es bastante estable, aunque me han llegado rumores
de problemas en máquinas con varios procesadores que se han resuelto el Service
Pack 1.
Otro punto importante a favor de SQL Server es la interfaz de acceso OLE DB
y ADO. Aunque se trata de una interfaz universal, SQL Server es una de las
primeras bases de datos en soportarla. Nuestros experimentos con ADO nos han
dejado muy buena impresión, y ya Delphi y C++ Builder 5 ofrecen componentes
nativos para ADO.
De todos modos siguen existiendo factores en contra de este sistema.
Solamente puede ejecutarse sobre ordenadores Windows. El lenguaje procedimental
es todavía bastante caótico, y la implementación de la integridad referencial
es demasiado restrictiva.
Se trata nuevamente de una de las bases de datos "históricas". La
arquitectura física es muy similar a la de Oracle. También puede ejecutarse en
varias plataformas: existe incluso una versión "personal" para
Windows 95/98. Y es similar a Oracle en otro aspecto importante: el precio.
Realmente, he encontrado la mayoría de las instalaciones de DB2 en el sector
industrial, en los departamentos informáticos de apoyo. Al parecer, en este
nicho IBM goza de mucho predicamento; de hecho, para mí fue gracioso
encontrarme por primera vez con redes token-ring en estas empresas.
Desde el punto de vista de la programación hay buenas y malas noticias. Las
buenas: el SQL de DB2 es muy potente; recordad que SQL se originó en
laboratorios de IBM. Es especialmente interesante la implementación de triggers.
Las malas noticias: los procedimientos almacenados de DB2 deben programarse en
lenguajes externos: C, Java, VisualBasic, etc. ¿Por qué esto es malo? No sólo
porque obliga a utilizar un lenguaje adicional, sino principalmente porque nos
hace depender de otro compilador ... que casi siempre está ligado a la
plataforma o sistema operativo.
Es difícil dar una receta para tomar una decisión tan importante como la
selección de un formato de datos para una aplicación, pero hay varios puntos
totalmente claros. Por ejemplo, mientras no haya un cambio en el producto, no
eligiría DB2, por su elevado precio y por los problemas de compatibilidad y de
facilidad de desarrollo de sus procedimientos almacenados. La versión 6 de
InterBase es gratuita y muy potente. Siempre que el número de conexiones
concurrentes no sea muy elevado (más de 100) puede confiar en él. SQL Server 7
es barato y relativamente bueno (olvídese de la 6.5), pero sólo lo utilizaría
en sistemas de 3 capas, pues es bastante complicado establecer reglas de
negocios en Transact-SQL. En cuanto a Oracle, su precio es prohibitivo, y la
potencia que ofrece requiere de un administrador de sistemas altamente
cualificado.
Resumamos. Yo seguiría el orden de preferencias que muestro a continuación:
por Ian Marteens
General Manager, Intuitive Sight