“Ana”
Nombre de una persona.
¿Cómo recuerda cosas una app?
Bases de datos y almacenamiento, desde cero. Usaremos una app de reseñas de videojuegos como ejemplo.
DATOSDÓNDE SE GUARDANBASES DE DATOSSQL Y NOSQL
Primero: ¿qué es un dato?
Un dato es un valor que la app usa o necesita recordar.
5
Calificación de un juego.
avatar.png
Imagen de perfil.
El contexto da sentido al dato: Ana calificó un juego con 5 estrellas.
Guardar es poder recuperarlo después
Escribir “Ana” en una pantalla no garantiza que siga ahí mañana.
01
Escribes
La app muestra el dato.
02
Cierras
La pantalla desaparece.
03
Abres
La app busca el dato guardado.
04
Recuperas
El dato vuelve a aparecer.
Si debe sobrevivir al cierre, necesita almacenamiento persistente.
¿Dónde puede vivir un dato?
Mientras está abierta
Ejemplo: texto que aún no envías. Puede perderse al cerrar.
En ese navegador o teléfono
Ejemplo: preferencia de tema oscuro.
Disponible para tu cuenta
Ejemplo: reseñas que ves al iniciar sesión en otro teléfono.
Antes de elegir una herramienta, pregunta: ¿quién debe poder recuperar el dato?
¿Qué es una base de datos?
Es un sistema para guardar datos de forma organizada y encontrarlos cuando la app los necesita.
Cada contacto tiene nombre y teléfono.
Puedes añadir un contacto, buscarlo, cambiarlo o borrarlo.
Cada reseña tiene autor, juego y calificación.
La app puede guardar la reseña y mostrarla más tarde.
La base de datos ayuda a conservar, organizar y consultar información.
Una forma de organizar: la tabla
Se parece a una hoja de cálculo: columnas para tipos de datos y filas para registros.
| ID | Nombre | Correo |
|---|---|---|
| 1 | Ana | ana@ejemplo.com |
| 2 | Luis | luis@ejemplo.com |
Una fila representa a un usuario. Su ID permite distinguirlo de los demás.
Cuatro acciones que hará tu app
CREAR
Guardar
Ana publica una reseña.
LEER
Mostrar
La app enseña la reseña.
ACTUALIZAR
Cambiar
Ana corrige su texto.
BORRAR
Eliminar
Ana quita su reseña.
Estas cuatro acciones suelen llamarse CRUD. Primero entiende la acción; después aprende el nombre.
¿Cómo llega una reseña a la base?
Tu appAna pulsa “Publicar”.
Servidor / APIRecibe la petición y revisa si Ana puede publicar.
Base de datosGuarda la reseña para recuperarla después.
La API es la puerta por la que la app pide leer o guardar datos.
¿Y si el dato es una foto?
Para archivos grandes usamos almacenamiento de archivos u objetos. Amazon S3 es un ejemplo de ese servicio.
Guarda la imagen
avatares/ana.pngEl archivo se puede recuperar con su ubicación.
Guarda la referencia
Usuario: Ana
Imagen: avatares/ana.png
Así la app sabe a quién pertenece.
S3 conserva el archivo; la base conserva los datos sobre ese archivo.
Caché: una copia para responder rápido
Si muchas personas piden la misma lista de juegos, la app puede guardar una copia temporal.
Cada petición consulta la base.
La base entrega la lista actual.
La lista puede salir de una copia rápida.
Cuando cambia, hay que renovar esa copia.
La base guarda el dato principal. La caché acelera algunas lecturas cuando hace falta.
Una app usa varios lugares a la vez
ReseñaBase de datosDebe seguir allí y verse desde otra sesión.
Foto de perfilS3 + referencia en la baseArchivo y dueño se guardan de forma distinta.
Tema oscuroDispositivoPuede ser una preferencia local.
Lista popularCaché, si hace faltaCopia temporal para consultas repetidas.
No tienes que usar todas estas piezas el primer día.
Las bases pueden organizarse de distintas formas
Filas y columnas
Usuarios en una tabla; juegos en otra; reseñas en otra.
Datos agrupados
Un juego puede guardar título, plataforma y etiquetas dentro de un documento.
Ambas formas guardan datos. La elección depende de cómo se usan y se relacionan.
Base relacional: tablas conectadas
“Relacional” significa que podemos relacionar registros de distintas tablas.
UsuariosAna tiene ID 1.
ReseñasUna reseña guarda usuario 1 y juego 8.
JuegosEl juego tiene ID 8.
Con esos números, la app puede saber quién escribió la reseña y de qué juego habla.
SQL: pedirle datos a una base relacional
SQL es un lenguaje para guardar, consultar y cambiar datos. Aquí solo leeremos una instrucción.
SELECT titulo FROM juegos;
“Muéstrame el título de cada juego.”
SELECT dice qué dato queremos.
FROM dice de qué tabla sale.
SQL es el idioma de la consulta; la base es el lugar donde están los datos.
No relacional y NoSQL, desde cero
Una base no relacional no usa tablas conectadas como su forma principal de organizar datos. “NoSQL” es un nombre común para esta familia.
{
"titulo": "Luz de ceniza",
"plataforma": "web",
"etiquetas": ["rol", "cooperativo"]
}
Un juego y sus datos juntos.
También existen bases de clave y valor: das una clave, como “juego-8”, y recuperas su valor.
NoSQL no significa datos desordenados. Al final verás ejemplos de clave y valor, columnas amplias y grafos.
¿Cuál escoger para el proyecto?
Útil si conectas personas, productos, pedidos o reseñas.
Las tablas ayudan a representar esas relaciones con claridad.
Útil si el dato principal se lee como un documento.
Puede servir para fichas con campos que varían entre registros.
Para empezar: escribe qué datos tienes y qué preguntas debe responder tu app.
Ahora: mapa de datos de su app
- Escriban tres datos que su app necesita recordar.
- Indiquen quién los crea y quién los lee.
- Decidan si viven en el dispositivo, una base o un servicio de archivos.
- Dibujen cómo se guarda uno y cómo se recupera.
“Una reseña la crea Ana y la leen otros usuarios.”
Va de la app a la API y luego a la base de datos. Al abrir el juego, la app la pide de nuevo.
Si pueden explicar ese recorrido, ya tienen el punto de partida de su proyecto.
Tres bases SQL que encontrarás a menudo
Las tres entienden SQL. Su historia y el lugar donde viven los datos son distintos.
PostgreSQL
Historia. Nació como el proyecto POSTGRES en Berkeley en 1986. Tomó el nombre PostgreSQL en 1996.
Ventaja. Puede exigir, por ejemplo, que cada reseña pertenezca a un usuario existente; también admite extensiones.
Úsalo para. Cuentas, reseñas, pedidos o reservas que se conectan entre sí.
MySQL
Historia. Su primera versión apareció en 1995 y se volvió muy usado en aplicaciones web.
Ventaja. Muchos proveedores, bibliotecas y tutoriales para aplicaciones web.
Úsalo para. Un blog, una tienda o un catálogo con usuarios y tablas relacionadas.
SQLite
Historia. El proyecto comenzó en 2000 para ofrecer una base pequeña y autónoma.
Ventaja. Guarda la base en un archivo y no necesita un servidor aparte.
Úsalo para. Datos locales de una app móvil o de escritorio y prototipos.
MongoDB: documentos en lugar de tablas
MongoDB es una base documental. Un registro puede guardar listas y datos anidados dentro del mismo documento.
¿De dónde salió?
La empresa nació como 10gen en 2007. La primera versión de MongoDB salió en 2009 para trabajar con datos flexibles a gran escala.
Ventaja. Una ficha puede reunir campos que cambian entre productos o juegos.
Úsalo para. Un catálogo donde cada tipo de artículo tiene características distintas.
Una ficha de juego
{
"titulo": "Luz de ceniza",
"plataformas": ["PC", "móvil"],
"modo": "cooperativo"
}Aun con campos flexibles, debes decidir cómo buscar y relacionar los datos.
Redis: datos listos para consultarse rápido
Redis trabaja principalmente en memoria. En nuestra app puede acelerar datos que se consultan muchas veces.
¿De dónde salió?
Salvatore Sanfilippo empezó Redis en 2009 para resolver un problema de escala en su propia empresa.
Ventaja. Acceso rápido y estructuras útiles para contadores, sesiones y listas ordenadas.
Juegos populares
La lista principal puede quedar temporalmente en Redis para responder a muchas visitas.
Úsalo para. Caché, sesiones, contadores o rankings que necesitan respuesta rápida.
Redis también puede guardar datos en disco, pero para este ejemplo la base principal conserva las reseñas.
Motor y servicio: dos nombres distintos
El motor es el programa que guarda y consulta datos. Un servicio administrado lo ejecuta y se ocupa de parte de su operación.
PostgreSQL / MySQLAmazon RDS ↗Ejemplo de servicio administrado para bases relacionales.
MongoDBMongoDB Atlas ↗Ejemplo de servicio administrado para documentos.
RedisRedis Cloud ↗Ejemplo de servicio administrado para Redis.
SQLiteDentro de tu aplicaciónUsualmente funciona sin contratar un servidor de base de datos.
Para su proyecto: elijan primero qué dato van a guardar; después decidan qué motor y quién lo operará.
Caso relacional: GitLab y PostgreSQL
GitLab contó que PostgreSQL guardaba casi todos los datos generados por sus usuarios. Al crecer, dividió esa gran base en dos.
Proyectos y actividad
Su aplicación necesita recuperar datos conectados: personas, proyectos y el trabajo que sucede en ellos.
Cuando la escala cambió, separó la base principal de la base de integración continua.
“Muéstrame las tareas de este proyecto y quién las abrió.”
Imagina tablas de usuarios, proyectos y tareas. Un ID conecta cada tarea con su proyecto y su autor.
Eso permite consultar relaciones y aplicar reglas, como impedir que una tarea apunte a un proyecto inexistente.
En su app: usuarios, juegos y reseñas tienen el mismo tipo de relación.
Caso local: Firefox y SQLite
Firefox guarda historial y marcadores en un archivo llamado places.sqlite dentro del perfil de la persona.
Una base dentro de la app
Firefox puede buscar un marcador o mostrar visitas anteriores consultando esa base local.
SQLite usa SQL y funciona sin levantar un servidor de base de datos separado.
Partida guardada en el dispositivo
partida.db → nivel, progreso, ajustesAl cerrar y abrir, el juego lee el archivo. Para verlo en otro dispositivo haría falta sincronizarlo aparte.
SQLite sirve cuando el dato debe sobrevivir localmente y una base de servidor no hace falta.
Caso documental: Sonic Forces y MongoDB
SEGA HARDlight publicó que ejecutó Sonic Forces: Speed Battle con MongoDB Atlas para soportar funciones en línea y muchos jugadores.
Datos ligados a cuentas
El estudio buscaba flexibilidad para datos de juego asociados a cada cuenta y capacidad para los picos de actividad tras un lanzamiento.
MongoDB guarda documentos que pueden agrupar campos y listas relacionados.
Un perfil de jugador
{
"jugador": "ana",
"personajes": ["sonic", "tails"],
"nivel": 12
}Este documento ilustra el modelo; no es un esquema interno publicado por SEGA.
Un documento es útil cuando esos datos se consultan juntos como una unidad.
Caso en memoria: Pokémon GO y Redis
Niantic usa Redis como caché para compartir datos de juego entre servidores cuando muchas personas se preparan para una incursión.
Una incursión muy popular
Muchos jugadores llegan al mismo lugar a la vez. Sus servidores necesitan responder con rapidez mientras se forma el grupo.
El estudio de caso reporta menos latencia en esa preparación al compartir datos mediante Redis.
Clave → dato que se pide seguido
incursion:123 → estado temporalRedis permite recuperar rápido una copia. Cuando cambia el estado, esa copia debe actualizarse o vencer.
La clave mostrada es un ejemplo de clase, no una clave interna de Niantic.
Redis brilla cuando la misma información se consulta muchas veces y la rapidez importa.
Caso de columnas amplias: Discord
Discord publicó cómo pasó de MongoDB a Cassandra y luego a ScyllaDB para guardar mensajes a una escala enorme.
Mensajes por canal y tiempo
ScyllaDB agrupa mensajes por canal y por una ventana de tiempo. Así puede buscar el historial de un canal sin recorrer todos los mensajes.
Este modelo se conoce como columnas amplias. Usa tablas, pero las organiza según las consultas previstas.
“Dame los mensajes recientes del canal 42.”
canal + periodo → mensajes ordenadosSe diseña primero la pregunta frecuente y luego la forma de agrupar los datos. Es una herramienta especializada para mucho volumen.
La lección para su app: elige el modelo pensando en cómo leerás los datos.
Caso de grafos: Call of Duty
AWS documentó que Activision Blizzard usó Amazon Neptune para representar recorridos y estados de jugadores de Call of Duty y personalizar experiencias.
Conexiones entre eventos
Un grafo guarda elementos y enlaces entre ellos. Sirve cuando la pregunta consiste en seguir varias conexiones.
La fuente habla de la franquicia Call of Duty; no atribuye esta arquitectura específicamente a Warzone.
Jugador → partida → escuadrón → evento
Podríamos preguntar qué experiencias conectan a varios jugadores o qué eventos ocurrieron después de una partida.
Este dibujo explica el tipo de pregunta; no representa el esquema interno de Warzone.
Un grafo ayuda cuando lo importante es recorrer relaciones, no solo guardar una ficha.
Primer paso para esta semana
Guarda un dato real de tu app.
Cierra la app, vuelve a abrirla y comprueba que puedes recuperarlo.
“Guardé ___ en ___ porque ___.”
Si es una imagen, explica dónde vive el archivo y dónde queda su referencia.
La IA también necesita buscar información
Dos textos pueden decir lo mismo con palabras distintas. Para reconocerlo, un modelo de embeddings convierte cada texto en una lista de números.
“Olvidé mi clave”
Un manual podría decir “Restablecer la contraseña”. Las palabras cambian, pero la idea es parecida.
[0.12, −0.37, 0.84, …]
Los números representan rasgos del texto. Un índice vectorial busca los fragmentos cuyos vectores están más cerca del vector de la pregunta.
Se conserva el texto original, su identificador y su vector para poder recuperar el fragmento correcto.
¿En qué cambia la búsqueda?
“Dame el usuario con ID 42.”
La base encuentra una fila concreta. Es lo que quieres para cuentas, pagos, inventario o permisos.
ID 42 → Ana“¿Cómo recupero mi acceso?”
La búsqueda vectorial devuelve textos cercanos en significado, aunque ninguno use exactamente esas palabras.
pregunta → fragmentos parecidosPuedes combinar ambas: comprobar primero qué documentos puede leer Ana y después buscar entre ellos los más parecidos.
Pinecone: búsqueda semántica ↗ · pgvector: consultas y filtros ↗
Un chatbot que responde con tus documentos
Este patrón se llama RAG: recuperar información relevante y dársela al modelo antes de que responda.
01
Preparar
Divides el manual en fragmentos pequeños.
02
Guardar
Creas un embedding para cada fragmento y lo guardas con su texto.
03
Buscar
Conviertes la pregunta en vector y recuperas los fragmentos más cercanos.
04
Responder
El modelo recibe la pregunta y esos fragmentos para redactar la respuesta.
Ejemplo: “Olvidé mi clave” recupera el apartado “Restablecer contraseña”. El modelo lo usa en esa respuesta; no hace falta volver a entrenarlo.
Pinecone y pgvector: dos caminos
Los dos permiten buscar vectores cercanos. La diferencia práctica es dónde viven y cómo los operas.
Pinecone
Es una base vectorial administrada. Creas un índice y consultas los fragmentos más similares; también puedes filtrar por metadatos como curso o idioma.
Úsalo si quieres un servicio dedicado a la búsqueda vectorial sin administrar ese índice dentro de tu PostgreSQL.
pgvector
Añade columnas de vectores y búsqueda por distancia a PostgreSQL. Puedes guardar usuarios, documentos y embeddings en la misma base y consultarlos con SQL.
Úsalo si tu app ya usa PostgreSQL y quieres empezar a buscar por similitud allí.
Dato útil: con pgvector puedes filtrar por curso_id en SQL y ordenar esos resultados por similitud.
¿Cómo “recuerdan” Codex y Claude Code?
El harness es el programa que conecta al modelo con herramientas, archivos y sesiones. Guarda el historial y prepara la información que el modelo recibe en cada turno.
Sesión guardadaMensajes, acciones y resultados.
Contexto preparadoHistorial relevante, instrucciones y resumen si hace falta.
ModeloLee ese contexto y produce la siguiente respuesta.
Conserva hilos con turnos y eventos para poder reanudarlos. Cuando la conversación crece demasiado, compacta el contexto que enviará al modelo.
Guarda transcripciones de sesión para reanudarlas. También puede cargar instrucciones de CLAUDE.md y notas de memoria del proyecto al empezar una conversación.
Detalle clave: el historial guardado puede ser mucho mayor que el contexto que cabe en el modelo. La búsqueda vectorial puede traer documentos externos relevantes; no es obligatoria para guardar una conversación.