Legfeljebb humorosan, csak kevesen értik. ;)
Felvezetoben azzal jossz a te megoldasod nem hasonlit egyik megszokottra se de mindegyiktol jobb, majd kiderul valojaban ugyanazokat a megoldasokat hasznalja, csak nem "hagyomanyosan" ezek egyiket hanem egy kevereket azokbol.
Bizonyára igazad van. Hiszen az sql szerver is ugyanazt az open/close/read/write/seek rendszehívásokat használja. Valószínűleg memóriában meg diszkre dolgozik, sőt lock-olni is tud. Tehát tökugyanaz.Bár nem tudom feltűnt-e, hogy senki nem ugrott nekem, hogy a 30M mentett álomány semmiség, mert az ő rendszere még ennél is többet tud tárolni, sőt nála sincsen semilyen performance gond, miközben 128 helyről 12 féle állomány ment garantált időn belül. Szóval csak van valami, amit nem pont úgy csinálok. ;) Tehát a ez az izé valami teljesen más, mint egy sql szerver. (Az sql szerver csak kiragadott példa!)
VAN a rendszerben sql is, amibe gyakorlatilag az index kerül bele mégegyszer: 1db gyűjtemény=1 sor.
Ezt jól le lehet kérdezni a webes programozóknak. ;)
Komolyan elmagyarázzam? Az sql szerver leállítása esetén is működik minden. Az sql csak azért van, hogy a web interfész (a rendszer <1%-a funkcióban) programozói jobban érezzék magukat. Ezen kívül tartalmazza az egyes munkaterületek konfigurációját, amit egy szkripttel lekérdezek (egyszer az életben), és a saját formátumra alakítom. A konfigurációs felület - amihez semmi közöm - már egy jó ideje nem működik. Ebből is látszik, milyen nékülözhetetlen eleme a teljes rendszernek. :D
Ráadásul egy fájl begyűjtése, megcsócsálása alatt átlagosan be sem tudom jegyezni az sql-be az egy sor indexet, avagy logot. Azaz a rendszer lényegesen gyorsabban dolgozik, mint az sql szerver. Bármilyen feledatra használnám, mindig várakozni kellene.
Ééés itt az utolsó tőrdöfés: Mindez egy Core i3, 4GB memória és 14TB bruttó (8db) diszken megy.