Definición
Una base de datos relacional guarda la información en tablas: filas que son registros y columnas que son campos, cada una con su tipo de dato. Lo que la hace "relacional" es que las tablas se conectan entre sí en lugar de repetir información.
En vez de guardar el nombre y la dirección del cliente en cada uno de sus doscientos pedidos, guardas el cliente una vez en su tabla y en cada pedido pones solo su identificador. Si el cliente cambia de dirección, lo cambias en un sitio.
Es el modelo dominante desde los años setenta y el que deberías asumir por defecto salvo que tengas un motivo concreto para no hacerlo.
Las piezas
Clave primaria. La columna que identifica cada fila de forma única. Normalmente un número que se incrementa solo, o un identificador aleatorio.
Clave foránea. Una columna que apunta a la clave primaria de otra tabla. Es la que crea la relación, y también la que hace que el motor te impida borrar un cliente que tiene pedidos. Esa protección es una virtud, aunque a veces moleste.
Tipos de datos. Cada columna tiene el suyo, y eso evita que se cuelen basuras. Un campo DECIMAL(10,2) para dinero nunca guardará "aproximadamente".
Restricciones. NOT NULL, UNIQUE, CHECK. Reglas que el motor hace cumplir aunque tu aplicación tenga un fallo. Es la última red de seguridad, y la más fiable, porque no depende del código.
Normalización. El proceso de repartir los datos para no repetirlos. Con llegar a lo que se llama tercera forma normal se cubre prácticamente todo lo que hace falta en una empresa.
Ejemplo práctico
Los dos proyectos que más uso llevan bases relacionales distintas por motivos distintos, y la comparación es instructiva.
El CRM de IMDICA usa MariaDB. Tiene clientes, pedidos, líneas de pedido, presupuestos, albaranes, expedientes, precios especiales por cliente. Docenas de tablas relacionadas entre sí, varios usuarios escribiendo a la vez, e informes que cruzan cinco tablas. Ahí un motor cliente-servidor es lo correcto.
El panel de AEWorks usa SQLite. Y no es una decisión de segunda: es una base de datos completa que vive en un solo fichero, sin servidor que administrar. Para un panel de una persona, con miles de registros y no millones, es más simple y suficientemente rápida. El fichero está fuera de la carpeta pública del servidor, así que no se puede descargar desde el navegador.
La lección que saco: el tamaño del motor tiene que corresponder al tamaño del problema. Montar PostgreSQL para un panel personal es tanto error como meter SQLite donde escriben cincuenta personas a la vez.
Cuál elegir
- PostgreSQL — El más completo y el más estricto con la corrección de los datos. Es la opción por defecto para un proyecto nuevo si no hay motivo para otra cosa.
- MySQL / MariaDB — Muy extendido, presente en cualquier hosting compartido. Sólido y bien conocido.
- SQLite — Un fichero, sin servidor. Perfecto para aplicaciones de escritorio, móviles, sitios pequeños y prototipos. Muy infravalorada.
- SQL Server / Oracle — Entornos corporativos donde ya hay ese ecosistema montado.
Errores comunes
- Guardar dinero en
FLOAT. Los decimales binarios no representan bien las cantidades monetarias y acabas con céntimos que no cuadran. Se usaDECIMAL. - No poner claves foráneas "para que no dé problemas al borrar". Ese problema es justamente la base de datos protegiéndote de dejar pedidos huérfanos.
- Fechas guardadas como texto. Ordenar y comparar se vuelve un infierno. Se usa el tipo fecha, y con zona horaria clara.
- Una tabla gigante con cuarenta columnas donde la mitad están vacías según el caso. Es señal de que hay dos o tres tablas ahí dentro.
- Cambiar el esquema a mano en producción. Para eso están las migraciones.
- No hacer copias, o no probarlas. Una copia que nunca se ha restaurado no es una copia: es una suposición.
Cuándo usarla
Sí —y esto es casi siempre— cuando los datos tienen estructura clara y relaciones entre sí, cuando la integridad importa (facturas, stock, pedidos) y cuando vas a necesitar consultas que crucen información.
No, o no como única pieza, cuando manejas documentos sin forma fija, cuando necesitas una escala de escritura enorme y distribuida, o cuando el dato es efímero. Ahí entra NoSQL, muchas veces junto a la relacional, no en su lugar.
