CreaRack-SL

Base de datos workspace · explicación coloquial

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:

AspectoPor qué D1 encaja
VolumenPocas miles de filas en total. SQLite va sobrado
LatenciaReplicado en edge — leer desde Madrid es local, sin viaje a un datacenter
CostePlan gratis de CF cubre todo el uso interno
OperaciónCero servidores que mantener. Wrangler CLI hace migrations
BackupsCF Pages + export wrangler periódico al DR backup
Multi-tenantNo hace falta. Es para 3 personas que confían entre sí
Edge runtimeEl 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:

TablaPara quéQuién la rellena
newsAnuncios del equipo (cards en home)Cualquiera vía create_news
notesPost-its de colores en el dashboardCompartidas entre los 3
alertsBanner activo en la parte alta del homeEdu o agente — pocas, alta visibilidad
reportsInformes generados por la IA (resúmenes semana, métricas)Cron + MCP
chat_messages + chat_typingChat 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:

TablaQué guarda
tasksTarea con título, estado, asignación, prioridad, due_date
task_attachmentsImágenes/PDFs subidos (los blobs viven en R2, aquí solo metadata)
task_commentsComentarios lineales (no threading)
task_calendar_eventsVínculo task ↔ evento Zoho Calendar
task_emailsVínculo task ↔ mensaje Zoho Mail

3. Herramientas personales (scope user)

A diferencia del dashboard, esto cada miembro lo tiene separado:

TablaPara qué
notebook_notesBloc de notas markdown personal (/tools/cuaderno)
directionsAgenda de contactos personas/empresas (/tools/direcciones)
quick_linksHub de URLs externos (Hetzner, GitHub, Holded, etc.)

Todas tienen owner_id (email CF Access) para separar lo de cada uno + archived_at para soft-delete.

4. OAuth y autenticación

TablaPara qué
auth_codesNonces de magic link (efímero, TTL corto)
zoho_oauth_tokensRefresh tokens Zoho por usuario (Edu/Dani/Txell). Inicialmente singleton (s67), migrado a per-user (s68)
zoho_oauth_stateStates 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_*:

BloqueTablasPara qué
Grafobib_nodes, bib_edges, bib_communitiesNodos del código (endpoints, modelos, docs) + relaciones
Metadata extendidabib_docs, bib_endpoints, bib_agentsDetalle por tipo de nodo
Searchbib_chunksFragmentos con embedding para búsqueda semántica
Wikibib_wiki_pages, bib_wiki_log, bib_wiki_contradictions, bib_wiki_utilityEl sistema wiki Supercontexto (esta misma página vive aquí)
Auditoríabib_index_runs, bib_change_log, bib_federationTracking 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

TablaPara qué
ai_eval_runsHistorial de runs de /tools/ai-eval (comparador de modelos LLM)
activity_logBitá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:

CapaDónde vivePara qué
Markdownsrc/content/wiki/*.md en el repo (git)Source of truth · renderizable por Astro
Metadata D1bib_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:

NivelCómoCuándo
CF autoSnapshots automáticos de D1 que mantiene CloudflarePermanente, sin acción nuestra
Wrangler exportCron en STAGE: wrangler d1 export → fichero .sqlDiario, /opt/dr-backups/d1-YYYY-MM-DD.sql
GitHubEl contenido de wiki (.md) vive en el repoGit 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:

AspectoCreaRack-ProWorkspace
MotorPostgreSQL 18Cloudflare D1 (SQLite edge)
Para quiénClientes SaaS de pagoEquipo interno (3 personas)
Multi-tenantSí (RLS estricto)No
Tamaño~55 modelos Django~25 tablas SQL plano
FKsEstrictasMínimas (D1 las soporta pero las usamos poco)
Backupspg_dump + per-tenantwrangler export + git
Donde correHetzner 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