V
na, ich schätze mal, die db in diesem spiel muß echt speed bringen. damit fliegen mysql und konsorten mit hohem bogen raus.
win und linux haben null problemo mit file mapping. also funktionen um MapViewOfFile bzw mmap. damit haste einfachen zugriff, als läge alles im ram und trotzdem wird nur geladen, auf was gerade wirklich zugegriffen wird.
danach gilt es, zu überlegen, welche datenstrukturen angesagt sind. für riesige datenmengen ist als kandidat wie immer der bayer-baum dabei. feiner können erweiterbare hashtables sein. solche ansatze sind aber nur einfach, wenn man keine polymorphie innerhalb der db braucht. naja, die relationalen dbs bringen ja erst recht keine.
es gibt dbs für c++, die genau das anbieten. wrapper ums filemapping mit bäumen und hashtables. leseanfang bei google unter post++. je nach zugriffsgewohnheiten biste durchaus auch um faktor 1000 über mysql dabei. schätze das spiel hat oft popelige einzelzugriffe wie "ändere von objekt mit id=0815 mal die x-koordinate auf 4711", und da nen sql-parser anzuschmeißen ist wirklich nicht ok.
die schrecklichen kosten: du kriegst nicht leicht ein absturzrecovery hin (keine transaktionen (ja, mysql leidet auch))! die großen datenbanke können das einfach. haut's denen den rechner aus, ist irgendwie nix inkonsistent. du müßtest am besten regelmäßig (z.b. stündlich) backuppen und beim abkacker den spielern nen time warp zumuten. oder, was ich für höchst elegant halte, ner backup-datenbank per tcp die ganzen buchungen auch schicken, steht die backup-bank im anderen haus, ist kaum ein echter verlust zu fürchten. und als wichtigstes beim tcpip-trick: dein sync() muß nicht auf nen plattenflush warten, netzbestätigung reicht, ist schneller als platte.
edit: so ein game könnte sehr viel mehr lesungen als schreibungen haben. dann ist Sgt. Nukems cache vor nen beliebig lahmen db auch sehr fein.
