Adatbázis (CouchDB / SQLite)¶

A DiKAS két adatbázis-szolgáltatót támogat. A szolgáltató az appsettings.json fájlban (Database.Provider) vagy környezeti változókkal állítható be — a kód azonos, minden funkció mindkét szolgáltatóval elérhető.

Szolgáltató	Felhasználás
CouchDb (alapértelmezett)	Szerver-/felhőüzem, több bérlő, replikáció
Sqlite	Egyedi munkahely, Android-alkalmazás, bemutató/fejlesztés

Az SQL Server már nem támogatott

Ennek az oldalnak a korábbi változatai harmadik szolgáltatóként a SqlServer-t is felsorolták. Ez (már) nem létezik — a Database.Provider csak a CouchDb és a Sqlite értéket ismeri.

Konfiguráció¶

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

A környezeti változók felülírják a fájlt — ez tesztekhez és telepítésekhez praktikus:

Változó	Jelentés
`Database__Provider`	`CouchDb` vagy `Sqlite`
`COUCHDB_URL`	Szerver URL-je, pl. `http://192.168.1.10:5984`
`COUCHDB_USER` / `COUCHDB_PASSWORD`	Hozzáférési adatok
`COUCHDB_PREFIX`	Adatbázis-előtag (telepítésenként/bérlőnként egyedi)

Az első indításkor a DiKAS automatikusan létrehozza az adatbázisokat ({prefix}_maindb, {prefix}_gastrocurrent), az összes nézetet tartalmazó design-dokumentumot és — üres adatbázis esetén — a bemutatóadatokat.

Bemutatóadatok és előzmények¶

Automatikus feltöltés: Egy üres adatbázist (SQLite vagy CouchDB) indításkor bemutató-törzsadatokkal tölt fel (termékek, személyzet, asztalok, ügyfelek).
Előzmények generálása (tesztekhez/kimutatásokhoz):

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

valósághű bizonylatokat, műszakokat és napi zárásokat hoz létre a megadott számú napra (tömeges írási sebesség ≈ 760 dokumentum/s). A bizonylat-, műszak- és zárási számok folytatódnak, a folyamatos üzem zökkenőmentesen kapcsolódik.

Teljesítmény (CouchDB)¶

A legfontosabb beállítási lehetőségek a 2 év előzménnyel (34.500 bizonylat) végzett terheléses tesztből:

Dátumtartomány teljes beolvasás helyett: Minden jelentés és operatív lekérdezés a bizonylatokat a bybizdate_docs nézeten keresztül tölti be (üzleti nap tartomány). A rövid időszakok így az adatbázis méretétől függetlenül gyorsak.
Előre összesített napi forgalom: A revenue_daily map/reduce nézet napi bontásban közvetlenül a CouchDB-ben összesíti a bruttó összeget, az adót és a bizonylatok számát. A GET /api/v1/reports/daily-aggregate?startDate=…&endDate=… végpont 2 év napi forgalmát kb. 0,1 s alatt adja vissza — ideális irányítópultokhoz.
Lassú lekérdezések naplója: Az 1 s-nál hosszabb nézetlekérések figyelmeztetésként jelennek meg a naplóban (nézet, sorok száma, időtartam, URL), és azonnal megmutatják a költséges lekérdezéseket.
Karbantartás: Nagy adatimportok után ütemezze be a _compact és a _view_cleanup futtatását — a dokumentumnézetek a bizonylatok egy másolatát tartják az indexben (tárhely a sebességért cserébe).

Felhőszinkronizálás¶

A helyi telepítések szinkronizálhatnak a központi felhős CouchDB-vel. A kapcsolat a szerver indításakor automatikusan a licencből (systemlic) kerül feloldásra: felhasználó = SyncLink (kisbetűvel), jelszó = SyncLink, távoli adatbázis = {DatabaseName}_{db}. Az appsettings.json kézzel kitöltött Sync szakasza felülírja a licencet. Kezelés és állapot: Adminisztráció → Beállítások → Rendszer → Felhőszinkronizálás (támogatói bejelentkezés).

Mód	Mechanizmus
CouchDb (helyi)	Natív CouchDB-replikáció: folyamatos push+pull bejegyzések a `_replicator` adatbázisban a `{prefix}_maindb` és a `{prefix}_gastrocurrent` számára (azonosítóminta `{prefix}_{db}_push` / `_pull`)
Sqlite	Az SQLite bekapcsolt replikációs módban a törlésekkel együtt egyezteti az adatokat a felhővel; az egymással ütköző változásokat a változás időpontja alapján oldja fel. A meglévő telepítések még a kiválasztott dokumentumtípusok régebbi egyeztetését is használhatják. Az ügyfélszolgálat átállítás előtt ellenőrzi az üzemmódot.
Felhő, több bérlő	Nincs szinkronizálás — az eszközök közvetlenül a központi adatbázison dolgoznak

A felhős adatbázis visszaállítása után az ügyfélszolgálatnak ellenőriznie kell, hogy az egyeztetés mindkét irányban teljes-e. Addig egy rendben lévőnek tűnő állapotkijelzés nem elegendő bizonyíték. A helyi adatokat ne törölje.

A natív replikáció beállításakor a rendszer eltávolítja azokat az elavult _replicator-bejegyzéseket, amelyek ugyanazokra az adatbázisokra mutatnak, de már nem felelnek meg az aktuális konfigurációnak (pl. a SyncLink vagy az adatbázisnév megváltozása után). Ha a SyncLink hiányzik a licencből, a saját bejegyzések törlődnek — a replikáció ekkor ki van kapcsolva. A feladat állapota (_scheduler/docs) a Felhőszinkronizálás oldalon jelenik meg; kapcsolódási hibák esetén a szerver 5 percenként újra megkísérli a beállítást.

Megjegyzések az SQLite-hoz¶

Adatbázisfájl: Dikas.Api.Web/dikas.db (a content root mappában, a munkakönyvtártól függetlenül).
A sémamigrációk indításkor automatikusan lefutnak (EF Core).
Áttérés CouchDB-re: készítsen biztonsági mentést, és állítsa vissza egy CouchDB-telepítésbe (lásd Biztonsági mentés és visszaállítás).