SQL tiene una larga y probada historia de éxito. Ha sobrevivido a todo el alboroto alrededor de NoSQL. Y aunque no es perfecto, ha demostrado ser el mejor lenguaje disponible para manipulación de datos. Esto no es sorpresa. La historia se puede remontar a la década de 1960s con el desarrollo de las bases de datos, una era marcada por la introducción de Integrated Data Store (IDS) en General Electric. Sin embargo, fue el modelo relacional de Edgar Codd el que revolucionó el manejo de datos. Su modelo, que transformó la representación de datos en una serie de tablas (o más estrictamente, relaciones), ha influenciado los sistemas de bases de datos desde entonces. Esta era también vio el nacimiento de SQL (Structured Query Language), que se convirtió en el lenguaje estándar para interactuar con bases de datos relacionales, incluyendo MariaDB y otras.
La utilidad de las bases de datos relacionales#
Entonces, ¿por qué necesitamos bases de datos y todo esto? Imaginemos que estás construyendo una aplicación, quizás una simple lista de tareas para llevar un registro de tareas diarias. Inicialmente, podrías pensar, “¿Por qué no simplemente guardar cada tarea directamente en un archivo?” Después de todo, mi lenguaje de programación tiene construcciones y bibliotecas para guardar y leer datos hacia y desde disco. Además, implementar esto suena sencillo: Crea una tarea, escríbela en un archivo; elimina una tarea, quítala del archivo. Estos son buenos puntos, sin embargo, a medida que la aplicación gana tracción, los usuarios comienzan a acumularse, y de repente, tendrás miles de usuarios intentando agregar, eliminar y modificar tareas simultáneamente. En este punto, la simplicidad de los archivos se convierte en fragilidad. Imagina que un usuario está actualizando una tarea en el exacto momento en que otro intenta eliminarla. O tal vez dos usuarios están editando la misma tarea al mismo tiempo. Con un sistema de archivos simple, es probable que termines con datos corruptos o perdidos porque no hay un mecanismo inherente para manejar tales conflictos.
Las bases de datos manejan estas situaciones con gracia a través de las propiedades ACID. Esencialmente, son un conjunto de principios que aseguran que incluso si la aplicación se bloquea en medio de una actualización, los datos permanecen consistentes y no se dejan tareas medio completadas colgando. Volviendo al ejemplo de la aplicación de tareas, imagina intentando mover tu tarea “Comprar comestibles” de pendiente a completado lo que requiere también cambiar la propiedad ultima_actualización, pero tu aplicación se bloquea justo en medio. Con una base de datos relacional, es todo o nada: O la tarea se marca como completa y la propiedad ultima_actualización refleja el nuevo valor de tiempo, o es como si nunca hubieras intentado actualizarla en primer lugar, evitando esos estados incorrectos a medias.
Ahora, consideremos los vínculos entre datos. En tu aplicación, las tareas pueden pertenecer a diferentes categorías o usuarios. En un sistema de archivos, mantener estos vínculos es engorroso. Podrías terminar con un archivo separado para cada categoría o usuario, pero entonces, ¿cómo encuentras rápidamente todas las tareas a través de categorías o aseguras que dos usuarios no terminen con el mismo ID de tarea? Las bases de datos tienen la capacidad de manejar relaciones complejas, lo que facilita la consulta de todas las tareas de un usuario específico o categoría, o incluso consultas más complejas como “muéstrame el número de tareas completadas para el usuario U agrupadas por categoría C durante el último mes”.
La seguridad es otro tema importante. En un sistema de archivos, si alguien obtiene acceso a tus archivos, tienen tus datos. Las bases de datos ofrecen características de seguridad robustas, como controles de acceso y cifrado, protegiendo tus datos de miradas no autorizadas.
Y luego está el tema del crecimiento. Tu simple aplicación de tareas podría evolucionar a una compleja herramienta de gestión de proyectos empresariales con el tiempo. Con un sistema de archivos, cada cambio puede sentirse como renovar un edificio con gente aún adentro.
Las bases de datos están construidas para ser flexibles y escalables, lo que significa que están diseñadas para crecer con las necesidades, ya sea agregando nuevas características o manejando más usuarios.
Al final, elegir una base de datos sobre un sistema de archivos simple es prepararse para el éxito mientras se está sobre terreno sólido. Se trata de asegurar que a medida que la aplicación crece, los datos permanecen seguros, consistentes y manejables, y tus usuarios felices. Después de todo, a nadie le gusta perder su lista de tareas debido a un bloqueo aleatorio o esperar eternamente a que sus tareas se carguen porque el sistema está sobrecargado manejando conflictos y búsquedas.
Un poco de historia#
Fue Edgar Codd quien propuso el Modelo Relacional para bases de datos y, dado que era matemático, formalizó los conceptos creando lo que se llama Álgebra Relacional y Cálculo Relacional. Todo esto era teórico, hasta que IBM y otros comenzaron a implementar los conceptos en proyectos académicos y de investigación. También querían idear un lenguaje estándar para consultar datos en bases de datos relacionales. Al principio inventaron QUEL (Querying Using the English Language) en la Universidad de California, Berkeley. En IBM, los investigadores querían idear su propio lenguaje y comenzaron un proyecto que percibo más como un juego entre colegas llamado SQUARE (Specifying Queries Using a Relational Environment). Esto llevó a un lenguaje de consulta que tenía una notación científica con subíndices y superíndices que era difícil de escribir en los teclados de las computadoras. Para resolver esto, redefinieron el lenguaje para usar solo caracteres estándar y de una manera ingeniosa y probablemente burlona amistosamente lo llamaron SEQUEL. Sin embargo, este nombre era una marca registrada en el Reino Unido, lo que les impidió usarlo. Eliminaron las vocales en SEQUEL y ¡boom! SQL nació. Para 1986, SQL se convertiría en un estándar ISO y ANSI.
Como una curiosidad histórica, aunque sus inventores tuvieron que renombrar SEQUEL a SQL, continuaron llamándolo “sequel”. Incluso hoy en día, muchos desarrolladores de software y profesionales de TI continúan pronunciándolo “sequel”. El nombre Structured Query Language (SQL) aparecería más tarde.
La utilidad de SQL#
SQL es un lenguaje declarativo, lo que significa que especificas lo que quieres obtener y no cómo obtenerlo. La base de datos se encarga de hacer lo que sea necesario para obtener los datos solicitados. SQL aísla la complejidad de la base de datos. Una base de datos es una pieza de software compleja con toneladas de algoritmos implementados en ella. Estos algoritmos tratan con diferentes formas de obtener datos almacenados en disco o memoria. Diferentes algoritmos son más eficientes en diferentes circunstancias, lo que incluye diferentes consultas y diferentes conjuntos de datos.
Por ejemplo, en MariaDB, un componente llamado optimizador de consultas se encarga de decidir qué algoritmos usar dada una consulta SQL y estadísticas recopiladas sobre los datos reales. El optimizador de consultas analiza la consulta SQL, las estructuras de datos, el esquema de la base de datos y la distribución estadística de los datos. Luego decide si usar un índice, qué algoritmo de unión es el mejor y cómo secuenciar las operaciones. Este proceso involucra una cantidad notable de complejidad y precisión matemática, todo lo cual la base de datos gestiona de manera abstracta para ti. Como desarrollador solo necesitas preocuparte por construir la consulta para obtener los datos que necesitas y dejar que la base de datos averigüe si usar o no un índice (con algunos conjuntos de datos, no usar un índice podría ser más rápido), árboles B, tablas hash, e incluso si agregar los datos a una caché en memoria, así como muchas otras cosas.
SQL también te permite manejar escrituras, es decir, crear y actualizar datos. También te permite definir el esquema de la base de datos, o en resumen y simplificando, las tablas y su estructura de columnas. De hecho, hay mucho más que SQL te permite hacer y su funcionalidad se puede dividir en cuatro categorías:
- Lenguaje de definición de datos (DDL): Crear y manipular el esquema.
- Lenguaje de manipulación de datos (DML): Insertar, actualizar y eliminar datos de la base de datos.
- Lenguaje de consulta de datos (DQL): Recuperar datos de la base de datos.
- Lenguaje de control de datos (DCL): Tratar con derechos y permisos sobre la base de datos y sus objetos.
En mis más de 15 años de experiencia en la industria, raramente he visto que se usen las categorías anteriores en un entorno de trabajo, con la excepción de DDL para referirse a actividades relacionadas con la actualización del esquema de la base de datos. Estas categorías son útiles principalmente en círculos académicos o en equipos que implementan software de gestión de bases de datos relacionales. Sin embargo, es bueno saber que estos términos existen y son utilizados por otros, ya que ayuda en las discusiones sobre la tecnología de bases de datos. Con esto en mente, permíteme tocar brevemente en una de esas discusiones.
Algunos dirían que los desarrolladores solo tienen que lidiar con DML y DQL mientras que DDL y DCL son una preocupación de los DBAs. En la práctica, esta división no es tan fácil de hacer. Los desarrolladores necesitan entender cómo se crean los objetos de la base de datos (como tablas y columnas) y cómo se gestiona el acceso a estos objetos. Sin embargo, es cierto que los desarrolladores pasan la mayor parte de su tiempo escribiendo sentencias SQL para modificar y consultar datos. Verás que este libro se centra en DML y DQL mientras explica otras categorías según sea necesario. Por otro lado, los DBA son expertos en todo lo relacionado con las bases de datos, desde la infraestructura y la gestión general de la base de datos hasta la optimización de consultas SQL y la migración, un DBA siempre es un cerebro valioso para tener en tu equipo.
Conclusión#
En conclusión, las bases de datos resuelven problemas reales que los desarrolladores de aplicaciones enfrentan, gracias a su capacidad para garantizar la integridad de los datos a través de las propiedades ACID, manejar relaciones complejas y proporcionar características de seguridad robustas. Aquí solo rasqué la superficie, pero esto debería ser suficiente para dar a los profesionales de TI novatos una rápida actualización sobre la importancia de las bases de datos relacionales y SQL.