Datenbank (CouchDB / SQLite)¶

DiKAS unterstützt zwei Datenbank-Provider. Der Provider wird in appsettings.json (Database.Provider) oder per Umgebungsvariablen konfiguriert — der Code ist identisch, alle Funktionen stehen mit jedem Provider zur Verfügung.

Provider	Einsatz
CouchDb (Standard)	Server-/Cloud-Betrieb, Multi-Tenant, Replikation
Sqlite	Einzelplatz, Android-App, Demo/Entwicklung

SQL Server wird nicht mehr unterstützt

Frühere Fassungen dieser Seite führten SqlServer als dritten Provider. Den gibt es nicht (mehr) — Database.Provider kennt nur noch CouchDb und Sqlite.

Konfiguration¶

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

Umgebungsvariablen überschreiben die Datei — praktisch für Tests und Deployments:

Variable	Bedeutung
`Database__Provider`	`CouchDb` oder `Sqlite`
`COUCHDB_URL`	Server-URL, z.B. `http://192.168.1.10:5984`
`COUCHDB_USER` / `COUCHDB_PASSWORD`	Zugangsdaten
`COUCHDB_PREFIX`	Datenbank-Präfix (je Installation/Mandant eindeutig)

Beim ersten Start legt DiKAS die Datenbanken ({prefix}_maindb, {prefix}_gastrocurrent), das Design-Dokument mit allen Views und — auf leerer Datenbank — die Demo-Daten automatisch an.

Demo-Daten und Historie¶

Auto-Seed: Eine leere Datenbank (SQLite oder CouchDB) wird beim Start mit Demo-Stammdaten gefüllt (Artikel, Personal, Tische, Kunden).
Historie generieren (für Tests/Auswertungen):

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

erzeugt realistische Belege, Schichten und Tagesabschlüsse für die angegebene Anzahl Tage (Bulk-Schreibrate ≈ 760 Dokumente/s). Beleg-/Schicht-/Abschluss-Nummern werden fortgeschrieben, laufender Betrieb schließt nahtlos an.

Performance (CouchDB)¶

Die wichtigsten Stellschrauben aus dem Lasttest mit 2 Jahren Historie (34.500 Belege):

Datums-Range statt Full-Scan: Alle Berichte und operativen Abfragen laden Belege über die View bybizdate_docs (Geschäftstags-Bereich). Kurze Zeiträume sind damit unabhängig von der Datenbankgröße schnell.
Vorverdichtete Tagesumsätze: Die Map/Reduce-View revenue_daily summiert Brutto/Steuer/Beleganzahl je Tag direkt in CouchDB. Der Endpoint GET /api/v1/reports/daily-aggregate?startDate=…&endDate=… liefert 2 Jahre Tagesumsätze in ~0,1 s — ideal für Dashboards.
Slow-Query-Log: View-Zugriffe über 1 s erscheinen als Warning im Log (View, Zeilenzahl, Dauer, URL) und zeigen teure Abfragen sofort an.
Wartung: Nach großen Datenimporten _compact und _view_cleanup einplanen — die Dokument-Views halten eine Kopie der Belege im Index (Speicher gegen Tempo).

Cloud-Synchronisation¶

Lokale Installationen können mit der zentralen Cloud-CouchDB synchronisieren. Die Verbindung wird beim Serverstart automatisch aus der Lizenz (systemlic) aufgelöst: Benutzer = SyncLink (lowercase), Passwort = SyncLink, Remote-Datenbank = {DatabaseName}_{db}. Eine manuell gefüllte Sync-Sektion in appsettings.json übersteuert die Lizenz. Verwaltung und Status: Admin → Einstellungen → System → Cloud-Sync (Support-Login).

Modus	Mechanismus
CouchDb (lokal)	Native CouchDB-Replikation: kontinuierliche Push+Pull-Einträge in `_replicator` für `{prefix}_maindb` und `{prefix}_gastrocurrent` (ID-Muster `{prefix}_{db}_push` / `_pull`)
Sqlite	SQLite gleicht Daten im aktivierten Replikationsmodus einschließlich Löschungen mit der Cloud ab; konkurrierende Änderungen werden nach dem Zeitpunkt der Änderung aufgelöst. Bestandsinstallationen können noch den älteren Abgleich ausgewählter Dokumenttypen verwenden. Der Support prüft die Betriebsart vor einer Umstellung.
Cloud Multi-Tenant	Keine Synchronisation — Geräte arbeiten direkt auf der zentralen Datenbank

Nach einer Wiederherstellung der Cloud-Datenbank muss der Support die Vollständigkeit des Abgleichs in beide Richtungen prüfen. Bis dahin genügt eine unauffällige Statusanzeige nicht als Nachweis. Lokale Daten nicht löschen.

Beim Einrichten der nativen Replikation werden veraltete _replicator-Einträge entfernt, die auf dieselben Datenbanken zeigen, aber nicht mehr der aktuellen Konfiguration entsprechen (z.B. nach Wechsel von SyncLink oder Datenbank-Name). Fehlt der SyncLink in der Lizenz, werden die eigenen Einträge gelöscht — die Replikation ist dann deaktiviert. Der Job-Status (_scheduler/docs) wird auf der Cloud-Sync-Seite angezeigt; bei Verbindungsfehlern versucht der Server die Einrichtung alle 5 Minuten erneut.

SQLite-Hinweise¶

Datenbankdatei: Dikas.Api.Web/dikas.db (im Content-Root, unabhängig vom Arbeitsverzeichnis).
Schema-Migrationen laufen beim Start automatisch (EF Core).
Für den Umzug zu CouchDB: Backup erstellen und in eine CouchDB-Installation zurückspielen (siehe Backup & Restore).