Base de datos workspace · explicación coloquial
Cómo está organizada la BD del workspace (la web interna del equipo), sin enterarse de cada columna. Para el schema completo ve a [[workspace-tech—bd—tecnico]].
En una frase
El workspace usa Cloudflare D1: una base de datos SQLite que vive replicada en el edge global de Cloudflare. Ni PostgreSQL, ni Mongo, ni servidor propio. SQLite plano, ~30 migrations aplicadas, ~25 tablas activas.
Por qué D1 y no PostgreSQL como CreaRack-Pro
El workspace es uso interno de un equipo de 3 (Edu, Dani, Txell). Las cargas son ridículas comparado con un SaaS de cara al cliente. Eso cambia las prioridades:
| Aspecto | Por qué D1 encaja |
|---|---|
| Volumen | Pocas miles de filas en total. SQLite va sobrado |
| Latencia | Replicado en edge — leer desde Madrid es local, sin viaje a un datacenter |
| Coste | Plan gratis de CF cubre todo el uso interno |
| Operación | Cero servidores que mantener. Wrangler CLI hace migrations |
| Backups | CF Pages + export wrangler periódico al DR backup |
| Multi-tenant | No hace falta. Es para 3 personas que confían entre sí |
| Edge runtime | El workspace corre en CF Pages Functions. D1 es el binding nativo |
Si el workspace creciera a 50 usuarios y necesitara queries SQL pesadas, tocaría replantear. Mientras no, D1 va perfecto.
Mapa mental: 6 dominios de tablas
erDiagram
HomeDashboard {
string news "anuncios"
string notes "post-its colores"
string alerts "banners home"
string reports "informes generados"
}
Tasks {
string tasks "tablero kanban"
string task_attachments "adjuntos R2"
string task_comments "comentarios"
string task_calendar_events "vínculo Zoho Calendar"
string task_emails "vínculo Zoho Mail"
}
HerramientasPersonales {
string notebook_notes "bloc personal markdown"
string directions "agenda contactos"
string quick_links "hub URLs"
}
OAuthYAuth {
string auth_codes "magic links"
string zoho_oauth_tokens "tokens Zoho per-user"
string zoho_oauth_state "anti-CSRF efímero"
}
Supercontexto {
string bib_nodes "grafo del codigo"
string bib_edges "relaciones"
string bib_wiki_pages "paginas wiki"
string bib_chunks "chunks para search"
}
Chat {
string chat_messages "mensajes equipo"
string chat_typing "estado typing"
}
Tools {
string ai_eval_runs "historial /tools/ai-eval"
string activity_log "bitacora MCP"
}
El diagrama es esquemático: muestra los 6 dominios y las tablas principales de cada uno. No es un ER formal (D1 tiene muy pocas FKs reales; las relaciones suelen ser convención).
Los 6 dominios uno por uno
1. Dashboard del home (colaboración del equipo)
Lo que ves al entrar a workspace.crearack.com:
| Tabla | Para qué | Quién la rellena |
|---|---|---|
news | Anuncios del equipo (cards en home) | Cualquiera vía create_news |
notes | Post-its de colores en el dashboard | Compartidas entre los 3 |
alerts | Banner activo en la parte alta del home | Edu o agente — pocas, alta visibilidad |
reports | Informes generados por la IA (resúmenes semana, métricas) | Cron + MCP |
chat_messages + chat_typing | Chat grupal estilo WhatsApp interno (s69) | Edu/Dani/Txell |
2. Tasks (tablero kanban del equipo)
El centro neurálgico del workspace. Una tabla principal + 4 que la extienden:
| Tabla | Qué guarda |
|---|---|
tasks | Tarea con título, estado, asignación, prioridad, due_date |
task_attachments | Imágenes/PDFs subidos (los blobs viven en R2, aquí solo metadata) |
task_comments | Comentarios lineales (no threading) |
task_calendar_events | Vínculo task ↔ evento Zoho Calendar |
task_emails | Vínculo task ↔ mensaje Zoho Mail |
3. Herramientas personales (scope user)
A diferencia del dashboard, esto cada miembro lo tiene separado:
| Tabla | Para qué |
|---|---|
notebook_notes | Bloc de notas markdown personal (/tools/cuaderno) |
directions | Agenda de contactos personas/empresas (/tools/direcciones) |
quick_links | Hub de URLs externos (Hetzner, GitHub, Holded, etc.) |
Todas tienen
owner_id(email CF Access) para separar lo de cada uno +archived_atpara soft-delete.
4. OAuth y autenticación
| Tabla | Para qué |
|---|---|
auth_codes | Nonces de magic link (efímero, TTL corto) |
zoho_oauth_tokens | Refresh tokens Zoho por usuario (Edu/Dani/Txell). Inicialmente singleton (s67), migrado a per-user (s68) |
zoho_oauth_state | States anti-CSRF del flujo OAuth (TTL 10 min) |
5. Supercontexto (la Biblioteca)
El sistema de grafo de conocimiento que mapea código ↔ documentación. ~13 tablas con prefijo bib_*:
| Bloque | Tablas | Para qué |
|---|---|---|
| Grafo | bib_nodes, bib_edges, bib_communities | Nodos del código (endpoints, modelos, docs) + relaciones |
| Metadata extendida | bib_docs, bib_endpoints, bib_agents | Detalle por tipo de nodo |
| Search | bib_chunks | Fragmentos con embedding para búsqueda semántica |
| Wiki | bib_wiki_pages, bib_wiki_log, bib_wiki_contradictions, bib_wiki_utility | El sistema wiki Supercontexto (esta misma página vive aquí) |
| Auditoría | bib_index_runs, bib_change_log, bib_federation | Tracking de indexaciones |
Detalle completo en el wiki [[crearack-tech—general—feature-catalog]] (sección Biblioteca) o en la página técnica [[workspace-tech—bd—tecnico]].
6. Herramientas auxiliares
| Tabla | Para qué |
|---|---|
ai_eval_runs | Historial de runs de /tools/ai-eval (comparador de modelos LLM) |
activity_log | Bitácora de operaciones MCP (auditoría general del workspace) |
¿Y los binarios? Imágenes, PDFs, audios
D1 NO guarda blobs. Para eso se usa R2 (object storage de Cloudflare, S3-compatible).
Patrón típico: la fila en D1 guarda metadata + clave R2 (r2_key), y el blob vive en R2.
tasks/{task_id}/{uuid}.png ← key R2
↓ metadata
task_attachments table en D1: r2_key, filename, content_type, size_bytes
Al borrar la task, el ON DELETE CASCADE limpia las filas D1, y el endpoint DELETE de la API se encarga de borrar también los objetos R2.
¿Y el contenido de la wiki?
Doble persistencia:
| Capa | Dónde vive | Para qué |
|---|---|---|
| Markdown | src/content/wiki/*.md en el repo (git) | Source of truth · renderizable por Astro |
| Metadata D1 | bib_wiki_pages | Índices, búsqueda, lint, links cruzados |
Cuando creas una página vía wiki_create_page MCP, hace commit GitHub + INSERT en D1 atómicos. Si solo se commiteara el .md sin pasar por el MCP (commits manuales), un job de reconciliación se encarga de actualizar D1 con la diferencia (sesión 18 implementó esto).
Backups del workspace
Tres niveles:
| Nivel | Cómo | Cuándo |
|---|---|---|
| CF auto | Snapshots automáticos de D1 que mantiene Cloudflare | Permanente, sin acción nuestra |
| Wrangler export | Cron en STAGE: wrangler d1 export → fichero .sql | Diario, /opt/dr-backups/d1-YYYY-MM-DD.sql |
| GitHub | El contenido de wiki (.md) vive en el repo | Git es el backup natural |
Si el workspace se rompe entero, recuperar: clone repo + wrangler d1 import del último dump.
Para el otro lado: la BD de CreaRack-Pro
CreaRack-Pro y workspace tienen filosofías opuestas porque sirven a clientes opuestos:
| Aspecto | CreaRack-Pro | Workspace |
|---|---|---|
| Motor | PostgreSQL 18 | Cloudflare D1 (SQLite edge) |
| Para quién | Clientes SaaS de pago | Equipo interno (3 personas) |
| Multi-tenant | Sí (RLS estricto) | No |
| Tamaño | ~55 modelos Django | ~25 tablas SQL plano |
| FKs | Estrictas | Mínimas (D1 las soporta pero las usamos poco) |
| Backups | pg_dump + per-tenant | wrangler export + git |
| Donde corre | Hetzner CCX (1 nodo) | Cloudflare edge (global) |
Si quieres entender CreaRack-Pro, ve a [[crearack-tech—bd—coloquial]].
Véase también
- [[workspace-tech—bd—tecnico]] — Schema técnico completo con migrations + relaciones
- [[crearack-tech—bd—coloquial]] — Hermana coloquial de CreaRack-Pro
- [[crearack-tech—general—feature-catalog]] — Qué hace la plataforma CreaRack Pro