En la actualidad existe una enorme oferta de sistemas de bases de datos, el modelo de base de datos más habitual es el relacional que tiene una vinculación estrecha con el lenguaje SQL que es el lenguaje de Bases de Datos estándar de facto y cuyas siglas significan Structured Query Language (Lenguaje Estructurado de Consultas)
Las bases de datos relacionales (RDBMS), son las más populares y extendidas de largo (Oracle DB, Microsoft SQL Server, MySQL, IBM DB2, Informix…) se estudian en todas las escuelas de informática del mundo y se basan en almacenar, relacionar, consultar y transferir datos dentro de tablas y registros o tuplas. Las tablas se relacionan entre sí por medio de campos compartidos y se pueden establecer muchas relaciones entre las mismas formando un entramado de datos super-organizado y estructurado.
Al crecer crecen los problemas
El principal problema de las bases de datos relacionales es precisamente que al crecer el volumen de datos suelen crecer las estructuras (Scale Up) y se convierten en verdaderos laberintos de conexiones que hacen que la organización y gestión de los datos pueda llegar a ser pesada y ralentice las famosas Queries así como la transmisión de datos. Para evitar que una base de datos relacional sea ineficiente se necesita, como si se tratase de un rascacielos, un buen arquitecto y un proyecto bien definido y mantenido en el tiempo, si falta alguna de ambas cosas nos veremos en un caos imposible de gestionar. Por supuesto los datos de mala calidad son el peor enemigo de una base de datos relacional, y superado el umbral de datos desactualizados o erróneos la totalidad de la base de datos se puede convertir en inservible.
Otro de los problemas de las bases de datos relacionales es que cuando tratamos de estructurar el mundo exterior nos encontramos que las cosas no son tan homogéneas como nos gustarían, que hay más tipos distintos de objetos similares de los que pensamos y más aún evoluciones o cambios de los mismos en el transcurso del tiempo. Cambiar la estructura de una sola tabla puede provocar impacto en otras muchas, cualquier variación supone un coste en compatibilidad, tiempo y recursos que puede llegar a ser importante.
Las bases de datos documentales para combatir el caos
El Alter ego de la bases de datos relacionales son las Bases NoSQL muy de moda estos días. Hablamos de bases de datos documentales como MongoDB o PostgreS… (Ojo también los fabricantes tradicionales disponen de módulos NoSQL). El modelo documental centra su valor en almacenar los datos en documentos en lugar de tablas. Los documentos son recipientes de datos en un formato semi-estructurado, que permite que un mismo tipo de recipiente almacene datos distintos de un mismo tipo de elementos. Otra de las características del modelo documental es que suele tratarse de software Open Source.
Por ejemplo, si quiero hacer una base de datos de empresas-clientes y quiero almacenar cualquier dato que pueda obtener de ese cliente, tengo dos opciones crear tablas relacionales con centenares de campos que puedan almacenar todos los tipos de informaciones posibles sobre ese cliente o bien crear un documento NoSQL en el que puedo almacenar información de cada cliente en documentos sin una estructura de campos fijos.
No podemos permitir el descontrol en NoSQL
Las ventajas de las bases de datos documentales es que son superflexibles y se adaptan a los cambios. En contrapartida un modelo más abierto abre puertas a la laxitud en la disciplina de la arquitectura y mal llevado acabará produciendo engendros que difícilmente funcionan y sin duda son ineficientes.
Hay otros modelos de base de datos, pero son estos dos los más populares hoy en día. ¿ Qué modelo elegir ?, en entornos concretos en los que se cuenta con información estandarizada y una clara fuente de datos sin duda el modelo relacional es el que se impone aún hoy. Sin embargo en modelos de información dispersa y no formateada el modelo documental puede ser mucho más eficaz. Internet, y la multiplicación de fuentes de datos hace que el modelo NoSQL sea una apuesta muy segura para el futuro, pero al SQL (antiguo SEQUEL) le queda aún larga vida.
Cada área siempre nos va a permitir disponer de múltiples opciones que nos permitirán adaptarnos a la solución más adecuada a nuestras necesidades. ¿Qué experiencias habéis tenido con estos sistemas? ¿Qué beneficios veis a unos sobre los otros? ¿Creéis que hace falta una solución nueva para gestionar las bases de datos?
