Database (CouchDB / SQLite)¶

DiKAS supporta tre provider di database. Il provider viene configurato in appsettings.json (Database.Provider) oppure tramite variabili d'ambiente — il codice è identico, tutte le funzioni sono disponibili con ciascun provider.

Provider	Impiego
CouchDb (standard)	Funzionamento server/cloud, multi-tenant, replica
Sqlite	Postazione singola, app Android, demo/sviluppo

SQL Server non è più supportato

Le versioni precedenti di questa pagina elencavano un terzo provider, SqlServer. Sono supportati solo CouchDb e Sqlite.

Configurazione¶

{
  "Database": { "Provider": "CouchDb" },
  "CouchDb": {
    "ServerUrl": "http://localhost:5984",
    "DatabasePrefix": "dikas",
    "MainDatabase": "main"
  }
}

Le variabili d'ambiente sovrascrivono il file — pratico per test e deployment:

Variabile	Significato
`Database__Provider`	`CouchDb`, `Sqlite`
`COUCHDB_URL`	URL del server, ad es. `http://192.168.1.10:5984`
`COUCHDB_USER` / `COUCHDB_PASSWORD`	Credenziali di accesso
`COUCHDB_PREFIX`	Prefisso del database (univoco per ogni installazione/tenant)

Al primo avvio DiKAS crea automaticamente i database ({prefix}_maindb, {prefix}_gastrocurrent), il documento di design con tutte le view e — su un database vuoto — i dati demo.

Dati demo e cronologia¶

Auto-Seed: un database vuoto (SQLite o CouchDB) viene riempito all'avvio con dati anagrafici demo (articoli, personale, tavoli, clienti).
Generare la cronologia (per test/analisi):

dotnet run --project Dikas.Api.Web -- --seed-history 730

genera giustificativi, turni e chiusure giornaliere realistici per il numero di giorni indicato (velocità di scrittura in bulk ≈ 760 documenti/s). I numeri di giustificativo/turno/chiusura proseguono in modo continuativo, l'attività in corso si collega senza soluzione di continuità.

Performance (CouchDB)¶

Le principali leve di regolazione emerse dal test di carico con 2 anni di cronologia (34.500 giustificativi):

Intervallo di date anziché scansione completa: tutti i report e le query operative caricano i giustificativi tramite la view bybizdate_docs (intervallo di giorni d'esercizio). I periodi brevi sono così veloci indipendentemente dalla dimensione del database.
Fatturati giornalieri precompattati: la view Map/Reduce revenue_daily somma lordo/imposta/numero di giustificativi per giorno direttamente in CouchDB. L'endpoint GET /api/v1/reports/daily-aggregate?startDate=…&endDate=… fornisce 2 anni di fatturati giornalieri in ~0,1 s — ideale per le dashboard.
Slow-Query-Log: gli accessi alle view oltre 1 s appaiono come Warning nel log (view, numero di righe, durata, URL) e mostrano immediatamente le query costose.
Manutenzione: dopo grandi importazioni di dati pianificare _compact e _view_cleanup — le view dei documenti mantengono una copia dei giustificativi nell'indice (memoria contro velocità).

Sincronizzazione cloud¶

Le installazioni locali possono sincronizzarsi con la CouchDB cloud centrale. La connessione viene risolta automaticamente all'avvio del server dalla licenza (systemlic): utente = SyncLink (lowercase), password = SyncLink, database remoto = {DatabaseName}_{db}. Una sezione Sync riempita manualmente in appsettings.json prevale sulla licenza. Gestione e stato: Admin → Impostazioni → Sistema → Cloud-Sync (login di supporto).

Modalità	Meccanismo
CouchDb (locale)	Replica nativa CouchDB: voci push+pull continue in `_replicator` per `{prefix}_maindb` e `{prefix}_gastrocurrent` (schema ID `{prefix}_{db}_push` / `_pull`)
Sqlite	In modalità di replica, SQLite sincronizza dati ed eliminazioni con il cloud; le modifiche concorrenti vengono risolte secondo la data di modifica. Le installazioni esistenti possono ancora usare la sincronizzazione precedente di tipi di documento selezionati. L’assistenza verifica la modalità prima del passaggio.
Cloud multi-tenant	Nessuna sincronizzazione — i dispositivi lavorano direttamente sul database centrale

Dopo il ripristino del database cloud, l’assistenza deve verificare che la sincronizzazione sia completa in entrambe le direzioni. Fino ad allora, uno stato apparentemente normale non dimostra la completezza. Non eliminare i dati locali.

Durante la configurazione della replica nativa vengono rimosse le voci _replicator obsolete che puntano agli stessi database ma non corrispondono più alla configurazione attuale (ad es. dopo un cambio di SyncLink o del nome del database). Se manca il SyncLink nella licenza, le voci proprie vengono eliminate — la replica è quindi disattivata. Lo stato del job (_scheduler/docs) viene mostrato sulla pagina Cloud-Sync; in caso di errori di connessione il server tenta la configurazione di nuovo ogni 5 minuti.

Note su SQLite¶

File di database: Dikas.Api.Web/dikas.db (nel content root, indipendente dalla directory di lavoro).
Le migrazioni di schema vengono eseguite automaticamente all'avvio (EF Core).
Per il trasferimento a CouchDB: creare un backup e ripristinarlo in un'installazione CouchDB (vedere Backup & Restore).