---
tipo: decisione
id: architettura-storage
nome: Architettura di storage — SQLite vs split DB/testo
aliases: ["Architettura di storage", "SQLite vs testo"]
coinvolge: ["Adrian", "Elon"]
lean: aperto
fonte: [sessione 02/07 — brainstorm Adrian]
aggiornato: 2026-07-02
---
Proposta di [[Adrian]] (brainstorm 02/07): centralizzare vault + collezione musicale in un `graphviewer.db` SQLite (`vault_nodes`, `vault_edges`, `music_*`); l'MCP interroga SQLite (`get_node`, `search_vault`, `get_neighbors`) invece di leggere `.md`. GraphViewer (in-house) legge **direttamente** da SQLite. Movente: la **massa documentale futura** (migliaia di PDF/email + sidecar) rende il filesystem di file sciolti un caos; un DB con **gate validante** (Adrian) previene sidecar orfani e path malformati. **Obsidian sostituito da GraphViewer**; correzioni via gate tecnico, non hand-edit (disciplina per tutti, Mauro incluso). Sussume la vecchia "motore di query" (rimandata a quando la mappa non sta più in contesto: quel momento è questo).

## La scelta non è binaria — due mosse separabili che la proposta fonde
- **(A) strato SQLite interrogabile** — query strutturate, performance GraphViewer, edge di prima classe.
- **(B) invertire la verità** — SQLite sorgente unica, `.md` ridondanti/cancellabili.
**Ogni guadagno viene da (A); nessuno richiede (B).** Tutto il rischio è in (B).

## Opzioni
- **Split** (`lean-Elon`, non di Mauro): DB per la **massa documentale** (sidecar/metadati/annotazioni delle migliaia di file, gate anti-caos) + **testo** per il **nucleo curato** (~56 nodi, leggibile/editabile/portabile). GraphViewer legge entrambi.
- **SQLite unico**: una sola fonte, coerenza in un posto, gate su tutto. Costo: si perde lettura-a-file diretta e portabilità del nucleo curato.

## Pro / contro
**Pro DB (fortissimi sulla massa documentale):**
- Gate validante: niente sidecar orfani, niente ghost da slash (il caso "Vendita Palmanova 213/A" con un DB non nasce). `fatto-riferito` (Adrian).
- Query strutturate; a scala grande *necessarie comunque* (= il motore di query rimandato).
- GraphViewer in-house legge SQLite direttamente.

**Contro DB-come-verità (solo sul nucleo curato):**
- Con **Obsidian→GraphViewer** e **correzioni via gate**, il vecchio contro "si rompe il loop di correzione a file" **si attenua molto** (`lettura-Mauro` 02/07).
- Verità = binario con schema (migrazioni, niente diff git, opacità) vs testo durevole/trasparente/portabile a vent'anni — **sovranità diretta di Mauro sulla memoria**.
- Raggio d'esplosione: `.md` corrotto = un nodo; `.db` corrotto = potenzialmente tutto (backup mitiga; il testo degrada con grazia, il DB no).
- Forense: `_archivio/raw/` è ri-derivabile *perché* testo.
- **`content` con wikilink va comunque parsato** per popolare `vault_edges` → il markdown non sparisce, si incapsula in TEXT. "Edge strutturati = niente parsing" regge a metà.
- Tensione **§7** ("niente seconda fonte di verità"): se SQLite è verità *e* i `.md` restano scrivibili+sync, sono due sorgenti. Principio: un solo deriver, tante viste.

## Nodo aperto — fissa il lean (per Mauro)
La verità del **nucleo curato** deve restare **testo leggibile-editabile**, o può diventare **DB interrogabile**? (La massa documentale va nel DB in entrambi i casi.) È scelta sul rapporto con la propria memoria, non solo tecnica.

## Riferimenti
- [[Stato del sistema]] — GraphViewer, automazione, struttura mappa-testo
- [[Strato annotazioni documenti]] — la massa documentale/sidecar è lo stesso territorio
- [[Adrian]] — il gate e il motore