Pulitura dei Parcheggiati

Pulitura dei Parcheggiati postato il 29/01/2008 17:20:29 nel forum programmazione, gdrcd, open source, hosting

Ciao a tutti.
Scrivo qui per sentire pareri e idee nuove da parte di chi sa usare gdrcd o chi sfrutta altri codici proprietari.
Il motivo è che vorrei diminuire i costi (in termini di processore) durante l'operazione di assegnazione stato "Assente" ai personaggi parcheggiati da xx minuti (non che il grande blu sia lento, al contrario, ma vorrei ottimizzare quest'ultima operazione prima di dedicarmi ad altro).
Questa discussione penso potrà essere utile anche ad altri in quanto proporrò le mie soluzioni.

Le idee che ho in mente sono due.

Prima soluzione
Avere un'unica tabella con elencati i personaggi e i loro dati. In questa tabella è presente un campo booleano {0,1} "presente" e un campo "evento" di tipo datetime che salva l'ultima operazione svolta dall'utente.
In una pagina tipo quella di login inserire una query (una volta ogni yy minuti) di tipo:
update utenti set online=0 where evento<(now()-interval xx minute)

Seconda soluzione
Avere una tabella con elencati i personaggi e i loro dati.
Avere una tabella "utenti_online". In questa tabella è presente un campo che identifica il personaggio e un campo "evento" di tipo datetime che salva l'ultima operazione svolta dall'utente.
Ad ogni login inserire nella tabella "utenti_online" l'utente.
In una pagina tipo quella di login inserire una query (una volta ogni yy minuti) di tipo:
delete from utenti_online where evento<(now()-interval xx minute)

Problemi:

Prima soluzione
Ogni yy minuti (che possono essere 30-60 mediamente) viene generata una query pesante in quanto il database deve scorrere l'intera tabella utenti, fare un'operazione sulle date, reimpostare il flag "presente" a tutti i risultati che soddisfano evento<(now()-interval xx minute)

Seconda soluzione
La query di cancellazione utenti online è leggera perchè pesca da una tabella poco estesa.
Il problema ricade però nella pagina di ricerca:
Quando si cercano gli utenti online bisogna fare una inner join dalla tabella "utenti_online" alla tabella "utenti" per estrarre i dati utili da stampare a pagina.

In gdrcd mi sembra che si modifica la soluzione numero due:
Dentro la tabella "utenti_online" ci si copia qualche valore tipo carica e araldica per evitare la inner join.
E' una soluzione che va a compromettere l'integrità del database perchè crea spontaneamente delle ridondanze.
Inoltre se io decidessi di voler stampare a video anche il parametro zzz durante la ricerca dovrei:
1) inserire un campo zzz nella tabella "utenti_online"
2) modificare ciò che voglio copiare in "utenti online" durante il login
3) modificare la pagina di ricerca

Non ci sono problemi in nessuna delle due soluzione finchè la tabella la tabella "utenti" contiene qualche centinaia di record.
Il problema subentra con molti utenti.

Qualcuno saprebbe confermarmi come funziona su gdrcd? Se funziona così in tutti i gdrcd?
Come qualche codice chiuso ha trovato soluzione?

Vi ringrazio e spero che le mie idee possano essere state utili a molti.


👋

---

quota

29/01/2008 18:05:04

Inanzi tutto ti ringrazio dell' invito a partecipare a questa discussione.

RomaImperiale.com utilizza delle APP e non il DB per gli online e quando salva dati nelle APP non crea una ridondanza che compromette il Database ma solo una ridondanza virtuale e temporanea.

Ad ogni modo se tu vuoi salvare l'ultima operazione in formato time e già hai implementato il sistema, nel momento in cui stampa la pagina degli online, nella cui tabella hai aggiunto il campo Data dell' ultima azione non potresti richiamare tutte le date e far eseguire un semplice IF di in fase di scrittura funzionante con una funzione che differisca le date?

Forse questa soluzione però è pesantina la più leggera forse è quella di lanciare la qry che pesca gli attivi, li stampa e metti infondo gli inattivi qry in cui non si rifà i conti ma stampa a video i rimanenti.


Idee buttate li. Comunque secondo me risparmi sicuramente più processore non facendo fare alcun Join di quelle dimensioni, questo è poco ma sicuro.

quota

29/01/2008 18:15:38 e modificato da shanks1 il 29/01/2008 18:16:29

La prima soluzione di cui parli è sicuramente molto pesante perchè la query andremme a prelevare tutti gli utenti (e sono tanti).

Non ho capito bene la seconda soluzione... sarebbe una query che comunque restituisce l'intera tabella utenti!?

Praticamente roma imperiale salva in ram tutti i dati degli utenti da presentare al momento della ricerca online, sbaglio?

Per ora non faccio join di quel tipo, ma sto valutando se mi possono convenire alla soluzione numero uno.

---

quota

29/01/2008 18:21:04

Potrebbe venirti in aiuto (se usi Mysql 5) La creazione di una View.

quota

29/01/2008 19:03:54

@mook:
ti ringrazio: mi hai fatto venire in mente che esistono view e trigger.
Le view non mi sono utili, ma con una piccolissima ridondanza di una variabile booleana si riesce a ottenere prestazioni OTTIME con l'utilizzo di un paio di trigger :D
Senza di te non ci sarei mai arrivato.

---

quota

29/01/2008 19:11:50

Tutto è bene quel che finisce bene u.u

---

quota

29/01/2008 19:18:46

Devo ammettere che i trigger sono utilissimi, mi sa che nei prossimi giorni il grande blu diventerà ancora più veloce :)

---

quota

29/01/2008 19:27:44

Volevo proporti dei trigger ma non sapevo che versione di Mysql usavi, nel senso che dalla 5.0 in poi i trigger si possono pure usare ma prima erano ancora "imperfette".

quota

30/01/2008 00:26:37

Però ogni volta che un utente chiama la pagina di ricerca vengono eseguiti controlli in più!
Mi sembra più pesante dato che deve comuque scorrere tutta la tabella degli utenti.
Preferisco una query leggera de eseguire 1-2 volte l'ora.

---

quota

London Vittoriana

Intervista ai gestori di London.. gdr ambientato nella Londra Vittoriana

The Bunny Hole

Intervista ai gestori di del GdR erotico The Bunny Hole - PlayBoy New York Edition

Tutorial per creare avatar

Video - Tutorial per realizzare, con photoshop, un avatar per gdr

Sword of Mystiria

Articolo di presentazione di TSoM a cura di Fantagiochi