SQL Server)¶

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
SqlServer	Infrastruttura Microsoft esistente

Configurazione¶

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

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

Variabile	Significato
`Database__Provider`	`CouchDb`, `Sqlite` oppure `SqlServer`
`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 / SqlServer	Servizio di sincronizzazione proprio: push/pull dei tipi di documento selezionati a intervalli (conflitti: Last-Write-Wins)
Cloud multi-tenant	Nessuna sincronizzazione — i dispositivi lavorano direttamente sul database centrale

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).