Cargando aplicación...
Preparando tu experiencia meskeIA
Tablas, claves, JOINs, índices y transacciones ACID — explicados visualmente
Los datos se organizan en tablas (relaciones). Cada fila es un registro único identificado por una clave primaria (PK). Las tablas se conectan mediante claves foráneas (FK) que referencian la PK de otra tabla. Haz clic en una FK para ver la fila relacionada.
| id_cliente | nombre | ciudad | |
|---|---|---|---|
| 1 | Ana García | ana@email.com | Madrid |
| 2 | Carlos López | carlos@email.com | Barcelona |
| 3 | María Ruiz | maria@email.com | Valencia |
| id_pedido | id_cliente | fecha | total |
|---|---|---|---|
| 101 | 2024-01-15 | 250,00 € | |
| 102 | 2024-02-03 | 85,50 € | |
| 103 | 2024-01-20 | 420,00 € |
| id_producto | nombre | precio | categoria |
|---|---|---|---|
| 1 | Laptop | 999 € | Electrónica |
| 2 | Teclado | 79 € | Electrónica |
| 3 | Mesa | 250 € | Muebles |
Elimina redundancia dividiendo datos en tablas relacionadas. En lugar de repetir "Ana García" en cada pedido, se almacena una única vez en clientes y se referencia por id.
La BD garantiza que toda FK apunta a una PK existente. No puedes crear un pedido con id_cliente = 99 si ese cliente no existe.
"Cada dato en un único lugar." Sin grupos repetidos, sin dependencias transitivas. Cada columna tiene un valor atómico (indivisible).
Conceptos avanzados para entender mejor las bases de datos relacionales
Un ORM (Object-Relational Mapper) es una capa de abstracción que permite interactuar con la base de datos usando objetos del lenguaje de programación en lugar de SQL directo. Ejemplos: Hibernate (Java), SQLAlchemy (Python), Prisma (JavaScript). Ventaja: menos SQL repetitivo. Inconveniente: puede generar consultas ineficientes si no se usa con cuidado.
Error clásico con ORMs: primero consultas N registros (1 query), y luego para cada registro haces otra consulta adicional (N queries). Total: N+1 queries cuando podría ser 1 con JOIN. La solución es el eager loading (incluir los datos relacionados en la consulta original).
PostgreSQL: más completo (JSON nativo, arrays, extensiones), cumplimiento SQL más estricto, mejor para consultas complejas. MySQL: más sencillo, enorme ecosistema, preferido en aplicaciones web tradicionales (LAMP stack). Ambos son excelentes opciones para la mayoría de proyectos.
Un índice sobre (ciudad, categoria) aprovecha la búsqueda si filtras por ciudad sola, o por ciudad + categoria. Pero NO si filtras solo por categoria. La regla: el índice solo es útil de izquierda a derecha, sin saltar columnas.