Qué significa tener SQL en el cliente

Has instalado un motor, entiendes qué se perdió al compilarlo, sabes por dónde se conecta al almacenamiento y has elegido sobre qué medio va a escribir. Queda la pregunta que justifica las cuatro lecciones anteriores y que casi nunca se hace con la seriedad que merece: qué cambia realmente en tu aplicación. La respuesta no es que las consultas sean más cómodas de escribir. Es que un conjunto entero de decisiones de diseño que habías tomado por obligación —desnormalizar, duplicar, mantener índices a mano, precalcular agregados, inventar convenciones de clave compuesta— deja de tener sentido, y a cambio aparecen obligaciones nuevas que en un almacén de objetos no existían. Esta lección hace ese inventario en ambas direcciones.

El planificador entra en tu cliente

Con cursores, el orden de las operaciones lo decides tú al escribir el código, y esa decisión queda congelada. Con SQL la decide un planificador cada vez que prepara la sentencia, consultando estadísticas sobre la distribución real de los datos. Es la diferencia entre un plan escrito por alguien que conocía los datos hace dos años y un plan escrito por algo que los conoce ahora.

Ese planificador es interrogable, y esta es probablemente la herramienta más infrautilizada de todo el nivel. Anteponer una instrucción de explicación a cualquier consulta devuelve, en lugar de los resultados, el plan que el motor piensa ejecutar: qué tabla recorre primero, qué índice usa, si construye una tabla temporal para ordenar o agrupar.

EXPLAIN QUERY PLAN
SELECT c.nombre, COUNT(*) AS n
FROM documentos d JOIN carpetas c ON c.id = d.carpeta_id
WHERE d.modificado_en >= :desde
GROUP BY c.id;

Dos palabras en la salida concentran casi todo el diagnóstico. Si aparece un recorrido completo de tabla sobre una tabla grande, falta un índice o el que hay no es aplicable. Si aparece una estructura temporal para ordenar o agrupar, el motor no ha podido aprovechar el orden de ningún índice y está materializando resultados intermedios. Ninguna de las dos es necesariamente un error —sobre trescientas filas da igual—, pero ambas son decisiones que ahora puedes ver, y verlas es exactamente lo que con cursores era imposible.

Un segundo mecanismo, menos vistoso pero igual de rentable, es la separación entre preparar y ejecutar. Compilar el SQL a bytecode cuesta trabajo; ejecutarlo con parámetros distintos, no. Reutilizar sentencias preparadas y vincular parámetros en lugar de concatenar cadenas es a la vez la optimización más simple del nivel y la única defensa correcta contra la inyección, que en el cliente sigue siendo un problema real en cuanto una consulta se construye con texto que escribió un tercero y que llegó por sincronización.

// Preparar una vez, ejecutar muchas, dentro de una sola transaccion
const st = db.prepare("UPDATE documentos SET archivado = 1 WHERE id = ?");
db.transaction(() => {
  try { for (const id of ids) st.bind(1, id).stepReset(); }
  finally { st.finalize(); }
});

Conviene además ejecutar el análisis de estadísticas después de la carga inicial de datos y de vez en cuando después. Sin estadísticas el planificador funciona con heurísticas genéricas; con ellas, elige el orden de las uniones sabiendo qué tabla filtra más. En una base local que se llena de golpe al sincronizar por primera vez, esa diferencia es visible a simple vista.

Índices de verdad

En un almacén de objetos un índice es, en la práctica, una vía de acceso por un campo o por una ruta de campos. Aquí el vocabulario es mucho más rico, y merece recorrerlo porque cada variante resuelve un problema que antes resolvías duplicando datos.

-- Compuesto: filtra por carpeta y devuelve ya ordenado por fecha
CREATE INDEX idx_doc_carpeta_fecha ON documentos(carpeta_id, modificado_en DESC);

-- Parcial: solo lo que la interfaz consulta a diario
CREATE INDEX idx_doc_activos ON documentos(modificado_en DESC) WHERE archivado = 0;

-- Sobre expresion: busqueda por titulo sin distinguir mayusculas
CREATE INDEX idx_doc_titulo_norm ON documentos(lower(titulo));

Lo que se rediseña

Aquí llega el cambio de fondo, y es más profundo que sustituir unas llamadas por otras. Todo el catálogo de deformaciones que aprendiste a aplicar sobre un almacén de objetos existía para compensar la ausencia de uniones. Guardabas el nombre del autor dentro de cada documento porque cruzar con la colección de usuarios costaba un recorrido entero. Mantenías contadores actualizados a mano porque contar significaba recorrer. Inventabas claves compuestas concatenando campos porque solo podías buscar por una vía. Duplicabas datos y aceptabas la incoherencia como precio.

Merece la pena mencionar dos capacidades que suelen decidir la adopción por sí solas. La primera es la búsqueda de texto completo, disponible como módulo compilado dentro del motor, que te da un índice invertido con ordenación por relevancia sobre datos locales: buscar entre los documentos del usuario deja de requerir servidor. La segunda son las funciones sobre documentos JSON, que permiten guardar una parte del modelo sin normalizar y aun así filtrar, extraer campos e incluso indexar expresiones sobre ellos. Entre ambas cubren el hueco por el que la mayoría de los equipos justificaba seguir con un almacén de objetos.

Nada de eso hace falta ahora, y sostenerlo es peor que inútil: es deuda. La normalización vuelve a ser asequible porque la unión la ejecuta el motor sobre páginas ya en su caché, sin materializar objetos intermedios ni cruzar ninguna frontera. Las restricciones de integridad —claves foráneas, unicidad, comprobaciones— pasan a estar declaradas en el esquema y verificadas por el motor, en lugar de vivir dispersas en funciones que alguien puede saltarse.

flowchart LR
subgraph Antes
  A1[Un objeto por registro] --> A2[Clonado estructurado por registro]
  A2 --> A3[Union manual en JavaScript]
  A3 --> A4[Agregacion en un bucle]
end
subgraph Ahora
  B1[Consulta declarativa] --> B2[Plan elegido por el motor]
  B2 --> B3[Ejecucion sobre paginas en cache]
  B3 --> B4[Una sola travesia con el resultado]
end
style A2 fill:#f38ba8,color:#11111b
style B4 fill:#a6e3a1,color:#11111b

Ese diagrama contiene el argumento cuantitativo del nivel entero. En el modelo anterior, el número de veces que un dato cruza la frontera entre el motor de almacenamiento y tu código crece con el número de registros examinados. En el nuevo, crece con el número de filas devueltas. Una consulta que examina cincuenta mil filas para devolver veinte pasa de cincuenta mil travesías a una. Y como aprendiste en la lección 3 del nivel 10, esa travesía es también la que va del Worker al hilo principal, de modo que el ahorro se cobra dos veces.

A cambio, tu capa de datos adquiere dos obligaciones que antes no tenía. La primera es un esquema explícito y versionado, con migraciones que se aplican en máquinas ajenas, sin supervisión y con todas las versiones anteriores conviviendo en el parque de usuarios. La segunda es más callada: las claves foráneas no se aplican por defecto y hay que activarlas en cada conexión, un detalle que ha costado incoherencias silenciosas a mucha gente.

// Al abrir, siempre, y en este orden
db.exec("PRAGMA foreign_keys = ON");
const version = db.selectValue("PRAGMA user_version");
for (const migracion of migraciones.slice(version)) {
  db.transaction(() => { migracion(db); });
}
db.exec(`PRAGMA user_version = ${migraciones.length}`);

Lo que SQL no resuelve

Conviene cerrar el nivel enumerando lo que sigue siendo tuyo, porque la euforia de tener un motor completo hace olvidar que el motor solo responde preguntas sobre los datos que ya tiene.

No resuelve la sincronización. Un fichero local con esquema y transacciones no converge solo con el de otro dispositivo; tener SQL no te da resolución de conflictos ni orden causal, y la captura de cambios sigue siendo trabajo tuyo, normalmente mediante disparadores que escriben en una tabla de bitácora. No resuelve la reactividad: el motor no notifica a tu interfaz que un resultado ha cambiado, y aunque en C existen ganchos de actualización y de confirmación, lo pragmático es que tu propia capa de escritura publique qué se ha tocado para que la interfaz invalide lo que corresponda. No resuelve la durabilidad, que sigue gobernada por el modelo de cuota del nivel 11 y por la ausencia de una sincronización real hasta el disco. Y no elimina la frontera del Worker: sigue siendo una interfaz remota que conviene diseñar gruesa, con operaciones de caso de uso y no con métodos finos.