[PROG] DB o non DB

Stavo pensando a cosa mettere in un DB e cosa no...
Certi dicono tutto, intendendo proprio tutto (stanze, con gli oggetti contenuti e i mob con le loro stat). Questo sistema dovrebbe garantire che un qualunque crash del mud server permette una ripartenza dal punto esatto dove era crashato... Ovvero crasherebbe di nuovo... Quindi non è una features utile. Un'altra cosa possibile di un mud interamente su DB è che più server potrebbero lavorare sullo stesso mud oppure un server può lavorare su più mud e queste sono cose molto buone; almeno apparentemente, perchè ora mi chiedo se sia effettivamente utile dato che solitamente i mmorpg utilizzano o server indipendenti oppure server che gestiscono zone del gioco, ovvero sempre cose molto disgiunte piuttosto che unite.
Il DB comune ha il difetto che se ha un problema va tutto a puttane, e la mia domanda è e se crasha il db server invece del mud server cosa succede? Se perdo un informazione vitale quanto ci metto poi a ripristinare a mano il sistema? Anche perchè il DB non è una cosa superiore ai file... E' un file lui stesso, ne più ne meno. I problemi sono esattamente gli stessi da quel punto di vista.
Questa ovviamente è il mio pensiero e mi piacerebbe che chi è esperto di DB si pronunci su questi dilemma...

JJ

Se posso essere considerato esperto, lavoro da oltre dieci anni con i database Oracle (e altri...), provo a dare il mio contributo.

Un DB è utile in quanto agevola la vita, quindi va valutata di volta in volta la scelta di mettere nel DB quello che sta più comodamente in un file. Agevolare la vita dell'amministratore il quale deve essere in grado di gestire backup in modo semplice ed efficiente. Agevolare la vita del programmatore in modo che possa usare SQL per accedere ai dati con maggiore facilità.
Tipicamente quindi un DB va usato quanto ci sono grandi quantità e varietà di dati da gestire in modo efficiente. Ma se SQL significa maggiore difficoltà, allora meglio lasciare il file; ci sono casi in cui il classico file piatto è più semplice da usare rispetto ad una tabella fra le tante: avere un file di testo consente una modifica più facile rispetto ad una tabella del DB, nel senso che si può usare direttamente un editor invece di strumenti di manipolazione del DB più sofisticati. Inoltre non va sottovalutata la possibilità di modificare un singolo valore mentre il MUD è in esecuzione per ripercuotere immediatamente l'effetto: talvolta il DB agevola questi interventi.

E qui bisogna scendere negli esempi; ovviamente, si tratta solo del mio punto di vista:
1. I file di configurazione o di customizzazione dei messaggi: questo genere di informazione di solito è di tipo read-once-only, sta meglio in un file, poiché viene letto una sola volta durante l'avvio del driver, e la loro modifica viene fatta solo dagli amministratori e molto raramente.
2. Le tabelle dei valori "standard" dei livelli in base alla razza, ecc. : questo genere di dati è anch'esso molto statico, ma se viene letto molto frequentemente, con ricerca di un singolo valore fra le migliaia, allora è più efficiente usare il DB anziché avere questi valori sparsi in dozzine di file o tenere tutto in RAM...
3. Le utenze/password (criptate), i messaggi e-mail, lo storico dei messaggi dei canali chat, ma anche lo stato e i valori dei giocatori... possono ricevere grande giovamento dall'uso del DB
4. I log di esecuzione invece probabilmente vanno meglio su file di testo.

Riassumendo: su file tutto ciò che è di sola-lettura (configurazione) oppure di sola-scrittura (log); su DB tutto quello che è dinamico e necessità di numerosi accessi in lettura/scrittura.

Va tenuto conto comunque che è ammissibile una situazione "ibrida", cioè tutto su DB ma con la possibilità di alimentare talune tabelle in modo massivo e/o automatico attingendo dal contenuto dei file (configurazione).

Tanto per finire in bellezza, da qualche mese ho scoperto SQLite, un DB veramente piccolo (all-in-one-file), leggero (driver-less), freeware, che si amministra con un plugin di Firefox (!) e che si integra facilmente con praticamente tutto: lo sto impiegando insieme a Perl (ne dubitavate?) per un mud fatto in casa...

M.

Ora come ora sono più propenso alla gestione dei dati su DB, che su file; per il semplice fatto che il DBMS può offrire dei servizi migliori rispetto al semplice File System, senza doverli implementare.
Eccezion fatta per log (incerto se usare semplici txt o xml, dipende da cosa ci si mette dentro) e dati di configurazione (XML potrebbe essere una valida soluzione).
Comunque per ora le mie parole pesano poco, non ho così tanta esperienza per affermare con certezza quale sia il sistema migliore, soprattutto nell'ambito dello sviluppo di un gioco.

Concordo con l' analisi di matt, specialmente se si decide che sia un M(maiuscolo)MORPG si rende necessario l'uso di db.
Per sqlite ho fatto anch'io delle prove:molto veloce, anche su transazioni +ttosto impegnative (gira anche su iPhone LOL)
Una curiosità: come ci si connette al file db sqlite(suppongo che il mud perl giri su linux)?
Ho fatto girare coffeMUD con fakeDB(su file praticamente) e gestisce una trentina di accessi correttamente, oltre non sono riuscito a provare.
Secondo me può andar bene anche MySQL.

Ottimo discorso mattsteel. E' il primo discorso obiettivo che sento sui db
C'è qualcuno che ha implementato il mud mettendo tutto sul db, anche le variabili di gioco... Follia! Comodo eh, ma follia pura.
I dati della configurazione posso stare benissimo in un db... Anzi è meglio perchè così l'update della configurazione può avvenire facilmente runtime e può essere bloccata in modo che non possa essere modifica da due persone contemporanemente.
I log invece sono d'accordo che debbano assolutamente stare in txt (o silmile) è solo un sovraccarico assurdo loggare sul db. Senza contare che è di nessuna utilità.

Sto usando mysql con php per un clone di ogame su un intel celeron a 450Mhz e l'unico peso sono i fastcgi per il resto il carico (molto intenso sul db, ogni azione del giocatore genera decine di query) è supportato egregiamente. Non ho la mia idea di cosa possa succedere con centinaia di giocatori però.

JJ

Premetto: perdonatemi se sono fissato con il Perl, ma ormai non riesco più farne a meno... è quasi una droga.

Parpacak ha scritto:DBMS può offrire dei servizi migliori rispetto al semplice File System

Jumping Jack ha scritto:Ottimo discorso mattsteel. E' il primo discorso obiettivo che sento sui db

Grazie JJ e Parpacak vedo che condividete il punto di vista.

macvart ha scritto:Concordo con l' analisi di matt, specialmente se si decide che sia un M(maiuscolo)MORPG si rende necessario l'uso di db.
Per sqlite ho fatto anch'io delle prove:molto veloce, anche su transazioni +ttosto impegnative (gira anche su iPhone LOL)
Una curiosità: come ci si connette al file db sqlite(suppongo che il mud perl giri su linux)?

Macvart, se ti riferisci al mio MUD è tutto scritto in Perl (driver, comandi, mob, stanze, pg...): attualmente sta girando su un WinNT, non ho ancora provato a portarlo sotto Linux, ma solo per pigrizia, visto che comunemente uso XP. La scelta è caduta su Sqlite solo perché è fornito "gratis" come libreria nel Perl 5.10 di ActiveState. La bellezza (ai miei occhi) di Perl è che (quasi) tutto può essere modificato a run-time: Perl consente di "scaricare" un sorgente precedentemente caricato e di "ricaricaro" dopo averlo modificato, mi ricorda tanto il vecchio LPC, insomma.
Attualmente sto usando un plug-in di Firefox (SQLite Manager 0.4.5)... un po' spartano ma ci si accontenta... Prima di usare il plug-in ho usato il pgm sqlite3.exe (un'interfaccia a linea di comando, come il Sql*Plus di Oracle o come OSQL.EXE di MS-SQL-Server tanto per capirsi). Non soddisfatto, all'interno del MUD ho reso disponibile (agli admin) il comando "sql" per lavorare "a vivo" sul DB del MUD tramite Telnet, pericoloso ma utile.

macvart ha scritto:
Ho fatto girare coffeMUD con fakeDB(su file praticamente) e gestisce una trentina di accessi correttamente, oltre non sono riuscito a provare.
Secondo me può andar bene anche MySQL.

Non ho mai provato a fare uno stress-test... al massimo ho provato con quattro utenti collegati contemporaneamente, decisamente pochetto, osservando "picchi" di CPU al 5% soltanto; invece se faccio girare il mud in debug all'interno dell'IDE ho visto picchi al 30%, (ma con intermezzi di un sec a 0%).

Dal quel poco che ho usato PL ne ho valutato la potenza, specie nelle ricerche testuali/manipolazione stringhe (ottimo per i mud direi)

mattsteel ha scritto:
Non ho mai provato a fare uno stress-test... al massimo ho provato con quattro utenti collegati contemporaneamente, decisamente pochetto, osservando "picchi" di CPU al 5% soltanto; invece se faccio girare il mud in debug all'interno dell'IDE ho visto picchi al 30%, (ma con intermezzi di un sec a 0%).

Più che i picchi puoi valutare il tempo cpu utilizzato che è più significativo, inoltre il picco in una rilevazione a 1 sec è già una media di quello che è successo in quel secondo, quindi se anche un solo utente ti manda al 100% di cpu per 2-3 decimi di secondo, con 10 utenti è facile che collassi. Come stress dovresti provare a generare un output folle, tipo 1000 linee e vedere cosa succede e quanta cpu (in tempo cpu) utilizza per quelle linee. In questo modo dovresti avere l'idea di cosa succederebbe con 10-20 giocatori. Se regge bene, aumenta le linee. Se vuoi un raffronto personalmente ho ottenuto 5000-10000 linee al secondo come output puro, oppure 40000 mob (300-400 per stanza) che combattevano tra di loro (con anche in stanza un personaggio che assisteva) su un dual P3 a 1000Mhz. Questo su codice base circle (quindi c) corretto e velocizzato (e con i cast ad area limitati ad un certo numero di target, mediamente una decina).
Invece, per valutare la bontà del db, ti consiglio di creare delle routine che simulano quello che potrebbe avvenire realmente e vedere quanti utenti reggerebbe. Credo che ci siano del programmi appositi ma non ne conosco.

JJ