Struttura DB

[Dyd666]

di che pagina parli. se parli della pagina gestione.php quello che vedi nel campo nome è il nome di rete del pc che hai messo ad elaborare per boinc.

Sisi parlo proprio di quella , svelato l'arcano , grazie

[Kappaloris]

lo scrivo qui dato che non trovo un topic più appropriato ed aprire uno nuovo è eccessivo:

aggiunti alle classifiche della flotta climateprediction e orbit@home

fatemi sapere se mancano ancora altri progetti.

[Schizzobau]

a costo di farti bestemmiare anche l'anima ora che probabilmente hai fatto tutto ed è funzionante, ma la tabella utenti non ha una lista di computer posseduti? quindi quando tu vuoi sapere il rac di uno schieramento devi zappare il db per trovare tutti gli utenti di $schieramento e per ogni utente zappare il db per trovare tutti gli ID.
Ovviamente è un esempio scemo però se tutte le operazioni sono gestite così diventa un incubo, ti conviene organizzare le tabelle in modo gerarchico: in cima hai gli schieramenti con gli utenti partecipanti, sotto gli utenti con i computer posseduti, così tratti col campo ID di ogni tabella ed è molto più efficiente.
Ancora meglio (ma non dipende dal DB) usa una cache in cui tieni i PC e ti levi una vagonata di interrogazioni: ad esempio calcoli RAC e CRD di un utente e lo salvi in cache così poi ripeschi per lo schieramento.
L'unico lato negativo di tutto è che un utente deve per forza avere uno schieramento

[Kappaloris]

a costo di farti bestemmiare anche l'anima ora che probabilmente hai fatto tutto ed è funzionante, ma la tabella utenti non ha una lista di computer posseduti? quindi quando tu vuoi sapere il rac di uno schieramento devi zappare il db per trovare tutti gli utenti di $schieramento e per ogni utente zappare il db per trovare tutti gli ID...

Le vecchie classifiche avevano una tabella per ogni singolo utente. L'esperienza mi ha insegnato che fintanto che restiamo nell'odine delle decine di migliaia di id è infinitamente meglio avere una tabella sola per tutti.

In particolare:

Gli utenti non sono definiti o completamente definibili nel mio database dal momento che la truttura ossea di questi (user id, nick, pass, email, ...) è nel db del vbulletin. Nel mio db metterò solo delle informazioni aggiuntive che comunque andranno a ""joinarsi"" (non si possono fare join tra db diversi) a quelle che ha il vb (in poche parole il mio userid sul vb è lo stesso che ho sulle classifiche).

Quindi, premesso che ogni volta che ci sono dei nomi da mettere devo chiamare la tabella del vb, a quel punto fare sulla tabella degli id una query:

"SUM (rac), SUM (crd), ... WHERE owner_id = 1,4,6,21,32,43,54,... GROUP BY owner_id"

(simil sintassi eh)

Morale 1 query mi basta per sapere tutto quello che mi interessa su un singolo schieramento a livello di utenza che lo compone(dando per scontato che la chiamata agli utenti del vb non si può mai saltare)(ed anche se a dire il vero molto spesso mi serve la precisione a singolo id per certi grafici).

Ed oltretutto la stessa identica query la posso riutilizzare per sapere le info di uno stesso schieramento nel tempo (ho una tabella per ogni mese che si salva la situazione nel tempo con precisione giornaliera).

Se ogni utente aveva una tabella a se, tra JOIN e salti vari mi sparavo.

Che poi il db soffra un pò di più in questo modo o meno, sinceramente non lo so, ma poco importa dato che prima di avere una quantità talmente grossa da ingolfare il server ne passeranno almeno 3 di generazioni di classifiche.

La storia della cache è più che vera ed ammetto che prima o poi ci ricorrerò anche se limitatamente, dopotutto mi piace che le classifiche siano il più fresche possibili.