¿Qué es SQL?

SQL (se suele pronunciar como la palabra inglesa sequel) son las siglas de Structured Query Languaje, y es el lenguaje que se usa para administrar e interactuar con bases de datos relacionales.

Frecuentemente el término SQL aparece junto a otros tales como postgres, MySQL o MariaDB. Éstos son ejemplos de lo que se llaman gestores de bases de datos.

Realmente SQL más que un lenguaje es un estándar que define una serie de características que debe tener una base de datos relacional. También contiene indicaciones sobre cómo debe ser la sintaxis para comunicarse con ella, entre otras cosas.

Los diferentes gestores son los programas que realmente gestionan la base de datos (supongo que por eso los llaman gestores…). Toman éste estándar como modelo y cada uno de ellos realiza algunas modificaciones sobre él. Algunos lo siguen de forma estricta (son implementaciones más puras), mientras que otros implementan características totalmente nuevas que no forman parte del mismo.

Bases de datos relacionales

Las bases de datos relacionales son sistemas que utilizan una serie de reglas y principios para garantizar la integridad de los datos que almacenan. Algunas de sus características principales son las siguientes:

Almacenan los datos en tablas normalizadas: las tablas en éste tipo de bases de datos son como las hojas en excel. Es decir, nos dan una serie de filas y columnas en las que podemos introducir datos. En excel, podemos organizar la información como queramos, y no hay ninguna limitación en el contenido de las celdas.

Las tablas normalizadas no permiten que organicemos la información como queramos, sino que imponen una estructura sobre ella. Cada columna de la tabla es una variable, y cada fila es lo que se llama un registro. Un registro puede representar los datos de una persona, de un producto disponible en nuestra tienda o de una casa a la venta en una inmobiliaria.

Cuando añadimos un registro nuevo éste adoptará todas las variables que tenga la tabla. No podemos añadir o quitar variables para un registro en particular, si queremos hacerlo tendremos que modificar la tabla entera. Además, en cada columna únicamente podemos añadir datos de un tipo específico. Por ejemplo, si tenemos una columna para almacenar la edad en años de algunas personas, la columna rechazará cualquier intento de añadir información que no sea un valor númerico.

En una tabla normalizada todas las filas tienen el mismo número de variables. En éste ejemplo, todos los datos están completos, pero podría faltar información en alguna casilla si el campo no existe para un registro.

Si bien puede parecer negativo que la base de datos sea tan estricta en lo que se refiere a la estructura de los datos, ésto es algo bueno, ya que la uniformidad hace que luego los datos sean mucho más fáciles de tratar y asegura que la estructura de los datos siga siendo la misma.

Permiten establecer relaciones entre los datos: supongamos que tenemos que construir una base de datos para una empresa que se dedica a alquilar maquinaria de obra (grúas, excavadoras, hormigoneras…) a otras empresas.

Nuestra empresa tiene clientes, por lo que la base de datos debe almacenar la información de cada cliente: un codigo, datos de pago… También necesitamos guardar los datos de las máquinas: número de unidades disponibles, precio por día…

Como cada cliente puede tener alquiladas varias máquinas, si intentamos almacenar toda ésta información en una única tabla acabaremos teniendo los datos del cliente y de las máquinas duplicados varias veces.

La solución es tener tres tablas. Una que contiene los datos de los clientes, otra que contiene los datos de las máquinas y una tercera tabla que almacena los datos de los alquileres. Cada fila de ésta última representa un alquiler, y contiene el código del cliente, de la máquina alquilada y otros datos de interés. Así, no duplicaremos ninguna información.

ACID: son las siglas de un conjunto de propiedades que definen cómo deben ser las transacciones en la base de datos. Por transacción entendemos operaciones como añadir o eliminar un registro a la base de datos, actualizar información contenida en la misma o recuperar un dato específico.

Gracias a éstas reglas, se garantiza la consistencia de los datos incluso en contextos en los que cientos de miles de usuarios están constantemente modificando y accediendo a la información.

Atomicity (atomicidad): cada transacción debe ser un conjunto indivisible e irreducible de operaciones, de forma tal que o todas terminan con éxito, o no se aplica ninguna.
- Si ocurre un problema al borrar un registro, es preferible que la operación se cancele antes que borrar la mitad de la información que contiene.
Consistency (consistencia): las bases de datos nos permiten definir muchas reglas que nuestros datos deben cumplir. Si se intentan añadir datos que no las cumplen, la base de datos no aceptará la transacción.
- Por ejemplo, si tenemos una columna para almacenar números enteros, no podemos añadir un texto a la misma.
Isolation (aislamiento): dos transacciones no deben poder operar al mismo tiempo sobre los mismos datos. Por ejemplo, si dos usuarios intentan modificar el mismo dato a la vez pueden llegar a corromperlo.
- Para evitar éstas situaciones los gestores de bases de datos deben implementar mecanismos que bloquean la información que está siendo modificada.
Durability (persistencia): los cambios aplicados con éxito deben permanecer indefinidamente a lo largo del tiempo, incluso aunque se produzcan errores en el futuro.
- Una vez que la información ha sido guardada en la base de datos, ésta debe permanecer inalterada ante eventos tales como fallos en el servidor, apagados inesperados, etc…

Gestores de bases de datos

Tal y como mencionamos anteriormente, SQL es un estándar que define una serie de características que debe tener una base de datos relacional. Acabamos de comentar algunas de ellas, pero hay muchas más. No obstante, todas las características recogidas en el estándar no son más que ideas o recomendaciones.

Los gestores de bases de datos son programas informáticos que implementan éstas ideas, y que nos permiten poner en marcha servidores para almacenar la información siguiendo las reglas que definidas en el mismo.

El estándar incluye una gran cantidad de especificaciones, pero cada gestor lo sigue un poco a su manera. Algunos gestores no implementan conceptos que forman parte del estándar, y a veces implementan otros que no forman parte del mismo.

Algunos de los gestores más populares son los siguientes.

Gestores cliente servidor

Éstos gestores están diseñados para ser ejecutados como un servidor al que pueden conectarse múltiples clientes para acceder a la información en remoto. Los datos se almacenan en un formato especial en el disco, y existe un proceso (el gestor) que actúa de intermediario entre los datos y las solicitudes.

Postgres: según mi experiencia es el que tiene el mejor rendimiento con bastante margen, especialmente cuando se tratan grandes volúmenes de datos. Su código es totalmente abierto y tiene una gran cantidad de complementos disponibles para extender sus funcionalidades.

MySQL: uno de los gestores más populares, de código “abierto” pero propiedad de Oracle. Al crear una tabla se pueden elegir distintos motores que determinan cómo se almacena la información en disco. Por ejemplo, uno de éstos motores permite guardar los datos en archivos de texto csv.

MariaDB: versión totalmente libre de MySQL. Diseñada para ser compatible con MySQL, de modo que pueda incorporarse en aplicaciones que utilicen ésta base de datos. Tiene prácticamente las mismas características que MySQL.

Hay otros muchos como por ejemplo SQL Server de Microsoft, Oracle DB…

¿Cuál de ellos elegir? Postgres es quizás la mejor opción por defecto, a no ser que tengas que utilizar otro por algún motivo. Si estás pensando en utilizar MySQL en un proyecto merece la pena echarle un vistazo a MariaDB. Es exactamente igual pero tiene un modelo de licencia más libre.

SQLite

SQLite es un caso especial. Casi todas las bases de datos relacionales son del tipo cliente servidor mientras que SQLite es más parecido a Excel. Es decir, la base de datos es un archivo que está guardado en el disco del ordenador y no hay ningún intermediario: las aplicaciones acceden a los datos leyendo el archivo directamente.

Por éste motivo no es recomendable utilizar ésta base de datos para aplicaciones que requieran acceso remoto a los datos. En lectura / escritura tiene las mejores cifras de rendimiento si no hay muchos datos (menos de 10 GB) y es muy liviana. Por éste motivo resulta ideal como base de datos interna para aplicaciones o para proyectos sencillos. También es muy útil como formato para almacenar datos como alternativa al propio Excel o csv.

Muchas aplicaciones de Android usan éste gestor para guardar datos en el propio teléfono. También lo usan los navegadores Firefox y Opera, o programas como Skype.

SQL y los diferentes gestores

Como hemos dicho, SQL es un lenguaje que forma parte de un estándar. Éste estándar define cómo debe ser la sintaxis para interactuar con la base de datos. Por ejemplo el estándar indica que para seleccionar todos los datos de una tabla utilizaremos la siguiente expresión: SELECT * FROM Tabla.

Además, si queremos filtrar los datos mediante una serie de condiciones, el estándar nos indica que debemos usar la cláusula WHERE. No obstante, hay algunos elementos que no están recogidos en el estándar, y cada gestor los implementa como quiere.

Imaginemos que queremos seleccionar los datos de las personas que nacieron en Madrid. En SQLite la consulta podría ser así:

SELECT * FROM personas
WHERE
  lugar_nacimiento == "Madrid"

Mientras que en postgres tendríamos que usar:

SELECT * FROM personas
WHERE
  lugar_nacimiento = 'Madrid'

Vemos que hay dos diferencias sutiles. La primera es que en SQLite podemos usar los operadores == y = (podemos usar cualquiera), mientras que en postgres debemos usar = obligatoriamente (== nos daría error). Además, para definir valores de texto, en SQLite podemos usar las comillas " o ', mientras que postgres nos obliga a utilizar '.

La sintaxis de ambos gestores para ésta consulta es prácticamente la misma, pero hay algunas diferencias. La segunda consulta sería compatible con ambos gestores, pero la primera sólo sería válida en SQLite.

Conclusiones

Las bases de datos relacionales permiten almacenar datos al tiempo que nos ofrecen una serie de ventajas:

Garantizan la integridad de los datos y su estructura: evitan la corrupción de los datos y otros muchos errores.
Permiten recuperar la información de forma eficiente: mediante filtros basados en condiciones se puede recuperar únicamente la información que necesitamos.
Almacenan los datos de forma segura: podemos controlar el acceso de cada usuario a los datos.
Gestión centralizada: al tener los datos en un único lugar todo el mundo tiene la misma información y no hay que andar gestionando mil copias diferentes de los datos.

Por tanto, cualquier información que sea importante debería estar almacenada en una base de datos. Herramientas como Excel pueden ser útiles para tareas básicas, pero en el momento en el que se trabaja con información delicada o que empieza a tener cierto volumen es necesario recurrir a éstos sistemas.

En general el gestor más recomendable es Postgres, pero para proyectos sencillos o prototipos SQLite viene muy bien ya que es más fácil ponerlo en marcha.