Bases de datos nosql
1. Estructura de los Documentos
En las bases de datos documentales, la unidad de almacenamiento es un documento que se representa generalmente en JSON o BSON (Binary JSON en MongoDB).
📌 Ejemplo de documento JSON en una base de datos documental:
1{ 2 "nombre": "Ana", 3 "edad": 25, 4 "email": "ana@email.com", 5 "direccion": { 6 "calle": "Av. Central", 7 "ciudad": "Madrid" 8 } 9}
👉 Un documento puede contener datos anidados, lo que permite organizar la información sin necesidad de varias tablas.
Diferencia con bases SQL
En SQL, tendríamos dos tablas para separar la dirección:
Tabla usuarios
| id | nombre | edad | |
|---|---|---|---|
| 1 | Ana | 25 | ana@email.com |
Tabla direcciones
| id | usuario_id | calle | ciudad |
|---|---|---|---|
| 1 | 1 | Av. Central | Madrid |
En NoSQL documental, todo está dentro de un solo documento sin necesidad de joins.
2. Normalización vs. Desnormalización
En bases documentales, podemos optar por dos estrategias para organizar los datos:
📌 Normalización (Referencias)
- Similar a las bases SQL
- Separamos datos en documentos diferentes y usamos una referencia (ID)
- Útil cuando los datos son repetitivos o cambian con frecuencia
📌 Ejemplo: Un pedido que referencia un usuario por su ID:
1{ 2 "pedido_id": "123", 3 "usuario_id": "abc123", 4 "total": 50.99 5}
El usuario se almacena en otro documento separado:
1{ 2 "id": "abc123", 3 "nombre": "Ana", 4 "email": "ana@email.com" 5}
🟢 Ventaja: Evita duplicación de datos
🔴 Desventaja: Se requieren múltiples consultas para obtener toda la información
📌 Desnormalización (Embedding)
- Se almacena toda la información dentro del mismo documento
- Útil cuando los datos no cambian mucho y se usan juntos con frecuencia
📌 Ejemplo: Un pedido con todos los datos del usuario embebidos:
1{ 2 "pedido_id": "123", 3 "usuario": { 4 "nombre": "Ana", 5 "email": "ana@email.com" 6 }, 7 "total": 50.99 8}
🟢 Ventaja: Consultas más rápidas (no se necesita buscar en varias colecciones)
🔴 Desventaja: Se pueden duplicar datos en varios documentos
👉 ¿Cuándo usar normalización y cuándo desnormalización?
- Si los datos cambian con frecuencia → Usar referencias
- Si los datos se consultan juntos siempre → Usar embedding
3. Relaciones en Bases Documentales
Aunque NoSQL documental no tiene joins como SQL, sí permite manejar relaciones entre documentos de dos maneras:
📌 1. Relación Uno a Muchos (Embedding)
Ejemplo: Un usuario con varias direcciones en el mismo documento.
1{ 2 "nombre": "Carlos", 3 "email": "carlos@email.com", 4 "direcciones": [ 5 { 6 "calle": "Calle Mayor", 7 "ciudad": "Barcelona" 8 }, 9 { 10 "calle": "Gran Vía", 11 "ciudad": "Madrid" 12 } 13 ] 14}
📌 Ideal cuando las direcciones no se comparten con otros usuarios
📌 2. Relación Uno a Muchos (Referencias)
Ejemplo: Un usuario con direcciones separadas en otra colección.
Colección usuarios
1{ 2 "id": "user123", 3 "nombre": "Carlos", 4 "email": "carlos@email.com" 5}
Colección direcciones
1{ 2 "usuario_id": "user123", 3 "calle": "Calle Mayor", 4 "ciudad": "Barcelona" 5}
📌 Ideal cuando las direcciones pueden pertenecer a varios usuarios
4. Estrategias para Optimizar el Modelado
✔️ Usar documentos pequeños:
- No almacenar información innecesaria dentro de un documento.
✔️ Elegir bien entre embedding y referencias:
- Embedding para consultas rápidas.
- Referencias para evitar datos repetidos.
✔️ Usar índices para mejorar la búsqueda:
- Si buscamos frecuentemente por
email, conviene crear un índice en él.