Struttura DB

[Kappaloris]

Posto qui la struttura del DB come l'ho pensata fino ad adesso... prego tutti gli esperti di database relazionali di farmi notare tutte le cavolate che faccio dato che io, forte della mia preparazione amatoriale dell'argomento, non so un'emerita ceppa :asd:

(i nomi dei campi sono qualitativi quindi non date loro peso)


Tabella ID:
-ID
-Possessore_ID
-Boinc_ID
-Nome
-CPU
-OS
-RAC
-CRD
-Ultimo_Contatto

Tabella Utenti (parziale dato che la joino con quella del vb per info quali password ecc ecc):
-ID
-Nick (join col db del vbulletin)
-Nome
-Cognome
-Data di nascita (join col db del vbulletin)
-Residenza (join col db del vbulletin)
-Schieramento
-Progetto preferito
-Avatar/foto
-Data JOIN
-Commento

Tabella Progetti_descrizione:
-ID
-Nome
-Sigla
-Descrizione
-Logo
-URL

Tabella schieramento_descrizione:
-ID
-Nome
-Descrizione
-Logo
-Data_creazione

Tabella Premi Assegnati:
-ID
-Utente_ID
-Premio_ID
-Data

Tabella Premi_descrizone:
-ID
-Nome
-Immagine
-Descrizione

Se avete esempi da chiedere chiedete pure :D

PS
Idee su come implementare la gestione dello storico? Una tabella per mese?

PPS
La gestione degli schieramenti permette di crearne di nuovi agevolmente ;)

[lele_core]

non sono un dba ma qualcosina la so.

con "Nick (join col db del vbulletin)" intendi dire "foreign key"? cioè che il campo Nick è legato con il campo XXX della tabella YYY del vbullettin contenente il nick dell'utente?
-Data di nascita (join col db del vbulletin) e
-Residenza (join col db del vbulletin) Possono essere vuoti?


storico: che dettaglio vuoi dare allo storico?


ad occhio ho visto che nelle tabelle
Tabella Premi Assegnati:
Tabella ID:
hai i campi Possessore_ID ed utente_ID, se questi si riferiscono all'ID utente allora possono essere altre due foreign key.

[Kappaloris]

asd si come dicevo i nomi sono indicativi, sono 2 campi uguali :D
li ho scritti come mi venivano cercando (male) di spiegare la loro funzione nel nome :)

Per il join col vb lo faccio semplicemente sulla base del primo ID, quello indice.

Quando un utente si registra, e conferma l'email, uno script crea un record nella tabella degli utenti con vb_user_id = all'id della mia tabella. Poi in futuro uso quella come chiave per joinare le tabelle.


Per lo storico a dire il vero non so ancora un cavolo asd bisognerebbe tenere in conto la velocità con cui rac e crediti cambiano per evitare di farla troppo precisa inutilmente ed allo stesso modo evitare di farla troppo imprecisa.


Dimenticavo, dall'ultimo contatto di un ID volevo poter mettere nella pagina informativa se il criceto era:

- Attivo (faccina verde?)
- Con problemi (faccina gialla?)
- Morto (faccina rossa?)

basandomi sulla data dell'ultimo contatto appunto. Ogni quanto si dovrebbe connettere un criceto al progetto? Cambia da progetto a progetto? perchè in quel caso dovrei mettere un campo nuovo nella descrizione del progetto per poter tarare questo sistema.

[lele_core]

asd si come dicevo i nomi sono indicativi, sono 2 campi uguali :D
li ho scritti come mi venivano cercando (male) di spiegare la loro funzione nel nome :)


si più o meno si capisce, chiedevo per sicurezza e per :spammone: :O
se le fai foreign key anche quelle riesci a tenere il db più pulito.. a me han sempre detto che quando crei un db è molto importante riuscire a legare le informazioni contenute tra di loro, e per far questo si usano appunto le foreign key.

Vincoli Interrelazionali [modifica (http://it.wikipedia.org/w/index.php?title=Vincolo_di_integrit%C3%A0&action=edit&section=5)]

Sono vincoli che definiscono legami tra due o più tabelle.
Il vincolo interrelazionale più utilizzato è quello di integrità referenziale: gli attributi di una data tabella (slave) possono assumere soltanto dei valori specificati in un'altra tabella (master). I vari linguaggi per basi dati solitamente implementano appositi costrutti per questo vincolo (ad esempio la foreign key o chiave esterna in SQL (http://it.wikipedia.org/wiki/SQL)).



relational databases (http://en.wikipedia.org/wiki/Relational_database), a foreign key is a referential constraint (http://en.wikipedia.org/wiki/Referential_integrity) between two tables.[1] (http://en.wikipedia.org/wiki/Foreign_key#cite_note-0) The foreign key identifies a column or a set of columns in one (referencing) table that refers to a column or set of columns in another (referenced) table. The columns in the referencing table must be the primary key (http://en.wikipedia.org/wiki/Primary_key) or other candidate key (http://en.wikipedia.org/wiki/Candidate_key) in the referenced table. The values in one row of the referencing columns must occur in a single row in the referenced table. Thus, a row in the referencing table cannot contain values that don't exist in the referenced table (except potentially NULL). This way references can be made to link information (http://en.wikipedia.org/wiki/Information) together and it is an essential part of database normalization (http://en.wikipedia.org/wiki/Database_normalization). Multiple rows in the referencing table may refer to the same row in the referenced table. Most of the time, it reflects the one (master table, or referenced table) to many (child table, or referencing table) relationship.
The referencing and referenced table may be the same table, i.e. the foreign key refers back to the same table. Such a foreign key is known in SQL:2003 (http://en.wikipedia.org/wiki/SQL:2003) as self-referencing or recursive foreign key.
A table may have multiple foreign keys, and each foreign key can have a different referenced table. Each foreign key is enforced independently by the database system (http://en.wikipedia.org/wiki/Database_system). Therefore, cascading relationships between tables can be established using foreign keys.
Improper foreign key/primary key relationships or not enforcing those relationships are often the source of many database and data modeling problems.




Per il join col vb lo faccio semplicemente sulla base del primo ID, quello indice.

Quando un utente si registra, e conferma l'email, uno script crea un record nella tabella degli utenti con vb_user_id = all'id della mia tabella. Poi in futuro uso quella come chiave per joinare le tabelle.


quindi se non ho capito male la tua tabella è generatrice di ID anche per il vbullettin.. su che db ti stai appoggiando?






Per lo storico a dire il vero non so ancora un cavolo asd


come lo volete lo storico? per progetto, come la classifica globale, altro?




bisognerebbe tenere in conto la velocità con cui rac e crediti cambiano per evitare di farla troppo precisa inutilmente ed allo stesso modo evitare di farla troppo imprecisa.


una tabella al mese o una per progetto o una per persona...

mmm che ne dici se per 15 giorni fai uno script che butta in una tabella la classifica globale ogni 15 minuti e poi vediamo che robaccia ci arriva su?

[Kappaloris]

ok allora ho letto 2 cosette sulle foreign keys e non è fattibile impostare un meccanismo simile poichè non posso toccare le tabelle del vb. secondo quanto scritto su html.it, per farlo entrambe le tabelle devono essere di tipo InnoDB, mentre quella del vb non lo è, e rischio di far danni a giocarci.

Oltretutto, sempre se ho capito bene, questo sistema è di protezione, cioè impedisce che mi venga a mancare una chiave necessaria ad un join. Dal db del vb nessuno va ad eliminare gli utenti se non io a mano e facendo sempre attenzione.

[lele_core]

ok allora ho letto 2 cosette sulle foreign keys e non è fattibile impostare un meccanismo simile poichè non posso toccare le tabelle del vb. secondo quanto scritto su html.it, per farlo entrambe le tabelle devono essere di tipo InnoDB, mentre quella del vb non lo è, e rischio di far danni a giocarci.


saggio ;)



Oltretutto, sempre se ho capito bene, questo sistema è di protezione, cioè impedisce che mi venga a mancare una chiave necessaria ad un join. Dal db del vb nessuno va ad eliminare gli utenti se non io a mano e facendo sempre attenzione.


ah, beh allora per quanto ne so io la struttura del db ci può stare.



per lo storico sarebbe fico avere una pagina con un calendario.. scegli un giorno e ti esce la pagina delle classifiche di quel giorno. Pensavo magari anche senza la possibilità di dettagliare quali pc avevo su un determinato progetto.. acnhe se... :asd:

[Kappaloris]

Allora, recapitolando... dobbiamo capire con che precisione fare lo storico e di cosa tenere traccia.

Sicuramente Crediti e RAC vanno registrati, immagino per ogni singolo ID, solo che succede se l'iD poi viene cambiato di propietario o eliminato? Allora converrebbe salvare uno storico per utente, questo però non ci permetterebbe di informazioni sul singolo ID.


Altrimenti si fa una tabella per mese strutturata grosso modo così:

-ID
-Giorno
-Possessore_ID
-RAC
-CRD
-CPU dell'epoca
-OS dell'epoca
Che si va a joinare con la tabella degli id descritta nel primo post per le info mancanti (cpu ecc ecc). Possessore non lo si joina poichè ci interessa il possessore dell'epoca e non quello attuale. E qui si che la storia delle foreign keys entra in gioco.

Poi si potrebbero ricavare molti grafici da questo credo. che vi sembra?

[Kappaloris]

Ah, dimenticavo... qui poi i merge però incasinano tutto lo storico :\

[lele_core]

Sicuramente Crediti e RAC vanno registrati, immagino per ogni singolo ID, solo che succede se l'iD poi viene cambiato di propietario o eliminato?


io credo che lo storico debba tenere la mia situazione di RAC e CRD in un istante. a questo punto le info necessarie sono mio_ID, rac, CRD, istante (o giorno chiamalo come preferisci). Poi avere anche CPU_del_tempo ed OS_del_tempo è fico così mi sgamo quale SO gira meglio con quale CPU (ma questo non dirglielo a nessuno shhhhh :) )

... in questo caso però non dovrebbe essere in join con una tabella attuale (forse solo con quella degli utenti sul campo possessore_ID) per non perdere le modifiche avvevute col tempo.

Per esempio la tabella che hai scritto non dovrebbe andar male..

-ID
-Giorno
-Possessore_ID
-RAC
-CRD
-CPU dell'epoca
-OS dell'epoca

se l'ID di un utente è immodificabile nel tempo (intendo se io posso anche cambiare nick sovrascrivendolo a quello vecchio ma l'ID non cambia), lo si usa per selezionare il record nella tabella insieme al giorno... a questo punto se chiedo "where utente=id_di_lele_core and giorno=12/06" in visualizzazione arriva il record con

id: 23293
giorno: 12/05/2008
possessore: possessore_ID, lo uso per recuperare il nick lele_core attuale, perchè adesso la gente mi conosce per questo nome... anche se ieri mi chiamavo Solid_snake ;)
rac: 0.07
cpu: intel Q6600
os: windows XP

in questo caso se io oggi regalo il mio ID_criceto a Il Capitano :asd: (o se lo cancello) comunque rimane nello storico che ieri era un mio criceto ed oggi invece sarà inserito come criceto de Il Capiatno ed andrà a popolare lo storico in un record con possessore_ID de Il Capitano.
quindi domani cercando nello storico "where utente=id_di_lele_core and giorno=13/06" non esce più un record con id:23293 mentre esce se cerco "where utente=id_di_Il_Capitano and giorno=13/06"

[lele_core]

Che si va a joinare con la tabella degli id descritta nel primo post per le info mancanti (cpu ecc ecc). Possessore non lo si joina poichè ci interessa il possessore dell'epoca e non quello attuale. E qui si che la storia delle foreign keys entra in gioco.



ma.. possessore_ID è un numero univoco identificativo di un utente o il nickname? :sospetto:

perchè nel primo caso vale il mio post precedente,
nel secondo caso non funzica più niente.

[lele_core]

Altrimenti si fa una tabella per mese strutturata grosso modo così:

-ID
-Giorno
-Possessore_ID
-RAC
-CRD
-CPU dell'epoca
-OS dell'epoca



che ne dici di metterci anche ID_progetto? complica ttroppo le cose?





qui poi i merge però incasinano tutto lo storico :\

perchè? non ho ben chiaro cosa succede quando si fa il merge di due cpu (ad esempio cpu:222 con CPU:334).. cosa compare poi nel progetto?

[Kappaloris]

Aaallorrraa... per ordine perchè hai scritto un patello :D
Prima cosa: dimenticanza imperdonabile; il progetto_id è ovviamente importante e va messo :stordita:

Poi, il fatto di eliminare un criceto sia dalle classifiche che da boinc, comporta che poi nello storico, alle voci CPU e OS attuali non ho nulla da metterci, che in ogni caso è poco male. E fin qui non ci sono problemi credo.

Gli ID degli utenti non cambiano mai :D
Il db del vbulletin mi da una bella mano nella gestione utenti :D

Il merge consiste nell'eliminazione dalle pagine ufficiali del progetto dell'ID mergiato e del trasferimento dei crediti dello stesso all'id nel quale si vuole mergiare l'ID vecchio.

Il merge di persè non falsa i dati... ma rende errato il continuo storico :D Falsa la linea temporale :asd:

[Il Capitano]

Mettiamo la seconda regola della flotta: mai fare il merge :D

[lele_core]

Il merge consiste nell'eliminazione dalle pagine ufficiali del progetto dell'ID mergiato e del trasferimento dei crediti dello stesso all'id nel quale si vuole mergiare l'ID vecchio.


ah... beh si potrebbe fare che una procedura automatizzata ogni tot ripulisce la tabella degli ID togliendo quelli che non compaiono più nei vari siti dei progetti, magari anzichè toglierli si manda una email al possessore_ID e si implementa il merge anche qui :asd:



Il merge di persè non falsa i dati... ma rende errato il continuo storico :D Falsa la linea temporale :asd:

:hahaha::hahaha::hahaha::hahaha: la linea temporale su questo forum :hahaha::hahaha::hahaha::sbonk:


Mettiamo la seconda regola della flotta: mai fare il merge :D

la seconda?? la prima è scaccolare solo progetti LO :)

scherzi a parte ci avevo pensato anch'io :asd:

[ThE-BlacK]

il merge ha a che fare con le meritrici o non centra niente?

[Demonbl@ck]

Ragazzi, mi sono prefisso l'obiettivo di rispondere in ogni 3d presente nel forum :cool:

[Kappaloris]

Posto qui una riflessione che ho fatto mentre scrivevo le classifiche.

Sto iniziando ad avere dei dubbi riguardo l'implementazione della gestione dei gruppetti (LO, tutù) dato che, come ben sapete, c'è boinc.italy che è il team, poi noi siamo dentro la community di hwu (il [HWU] nel nome del profilo della flotta serve a giga per metterci in quella comunità) all'interno della quale c'è la flotta che contiene diversi utenti.

Mi sembra una matrioska.

Che ne pensate?

[ricky_4]

anche secondo me non c'è bisogno, se qualcuno vuole vedere chi tra i 2 scaccola di più si prende una calcolatrice e fa 2 conti :asd:

[RadioactiveToy]

A noi piace mettere una cosa dentro a un'altra :oink::O

In effetti è un po' confusionaria come cosa, uno che arriva qua e vede il gruppo all'interno del miniteam di un team che a sua volta fa parte di una community potrebbe andare un tantino in confusione

Per ora direi di lasciare stare, tanto siamo 4 gatti, facciamo presto a vedere chi ha più rac. Magari quando ci saranno più utenti potrebbe tornare più utile.

[iCasty2005]

Concordo. ;)

[Kappaloris]

Dunque, tanto per far notare che non sono qui a far nulla, sto iniziando a popolare il database coi vostri vecchi id. A mano.
E' un lavoro così palloso che se mettevo un amanuense a farlo, a quest'ora si sarebbe già suicidato.
E per quelli che pensano che potrei fare uno script per farlo automaticamente rispondo che uno script non si accorgerebbe delle porcate che avete fatto in quel povero database.

C'è qualcuno che ha preso un suo id e l'ha aggiunto per tutti i progetti e cose simili. L'unico ad avere un discreto quantitativo di id e messi in ordine è n-gage, al quale vanno i miei complimenti.

E devo ancora passare falco e theboiamond... mi sento male solo al pensarci :cry:

[Kappaloris]

Un altro pulito è UR.... per una volta un tutu che fa qualcosa di buono :rolleyes:

[ricky_4]

Un altro pulito è UR.... per una volta un tutu che fa qualcosa di buono :rolleyes:
dai che pure con me ti dovrebbe andare bene :look:

[RadioactiveToy]

E devo ancora passare falco e theboiamond... mi sento male solo al pensarci :cry:
Ti invidio proprio
Se serve una mano sono qua, tanto sono in ferie senza una cippa da fare :D

Un altro pulito è UR.... per una volta un tutu che fa qualcosa di buono :rolleyes:
:O:O:O:O:O:O:O:O:O:O:O:O:O:O

[Il Capitano]

Anche io sono ordinato, è solo che ho troppi ID :O

[lele_core]

Anche io sono ordinato, è solo che ho troppi ID :O


:hahaha::hahaha::hahaha::hahaha::hahaha::sbonk:

[Kappaloris]

Per te capitano il problema non si è neppure posto.... inserito il primo id e cestinati gli altri :asd:
:sofico:

[Il Capitano]

Per te capitano il problema non si è neppure posto.... inserito il primo id e cestinati gli altri :asd:
:sofico:Interessante soluzione, un pò come se io vengo a casa tua, ti gambizzo e cestino il resto del tuo corpo :O

[Kappaloris]

Dunque, terminato di popolare il database ed ora sto facendo funzionare gli script per aggiornare i dati.

Devo ammettere che dopo aver preso un po' di tempo a studiare la sintassi sql (per quel poco che ne conosco) il codice appare più snello ed elegante.

Anche il procedimento di aggiunta dei progetti è decisamente più facile e difatti credo che creerò un pannellino di amministrazione così da poter sbolognare parte del lavoro ad altri (qualcuno ha detto capitano?). L'unico progetto rognoso è rosetta che mi ha fatto cristare a nastro :botte:

Forse versione embrionale delle classifiche UP già in nottata (si, per me è molto tardi, non molto presto).

[Kappaloris]

http://flottastellare.com/

Ecco una versione fatta al volo delle classifiche.
Per ora è solo la classifica globale ordinata per rac ed amen.
Ripeto, è tutto messo lì giusto per avere qualcosa.
Lo stile del sito sarà quello che vedete, con alcune aggiunte.
Siccome non sono un designer, ho privilegiato la chiarezza delle classifiche ad uno stile + complicato (che magari manco sarei riuscito a realizzare bene).


Detto questo, pian piano arriverà anche il resto.
Buona notte!

PS
sì, i valori non sono molto convincenti... poi vedo.

[ricky_4]

bravo kappino, buon lavoro per ora :O

[RadioactiveToy]

Bel lavoro K, aspettiamo con ansia la versione definitiva :D


Tanto per andare un po' OT, sono orbo io o c'è una funzionalità nuova a fondo pagina dei thread? :stordita:

[ricky_4]

Bel lavoro K, aspettiamo con ansia la versione definitiva :D


Tanto per andare un po' OT, sono orbo io o c'è una funzionalità nuova a fondo pagina dei thread? :stordita:
i tag, vista ora :look:

[Kappaloris]

perchè non avete visto i profili degli utenti... pianpiano il vb sta diventando myspace lol

[Kappaloris]

Piuttosto, avete notato come i rac nella classifica siano abbastanza bassi... eppure nè mi sembra ci siano errori nel codice, e quando ho aggiunto un mio nuovo id tutto è andato bene.

Quindi, chi ha voglia, mi mandi un pm che gli passo tutti i suoi ID per provare a fare una somma a mano. (nella pagina vedete anche quanti ID avete in modo da quantificare quanto ci mettete. sconsiglio a falco di applicarsi con 117 id :asd:)
Io ora provo a farlo per me.

[Kappaloris]

RIRIEDIT


Pare che dopotutto i valori siano giusti anche secondo boincstats. Togliendo Reisel che non funziona al momento e WCG che non so come farò ad aggiungere, il totale dei crediti bene o male torna. Quindi, pare proprio che la flotta si sia ammosciata in termini di RAC.

[Il Capitano]

Secondo me le vacanze hanno portato un pò di pc degli uffici spenti, quindi è normale il calo di rac.

tra l'altro anche il mio quad era spento quando sono tornato. Ora ha un rac di solo 200 :angry:. ma lo frusterò come si deve per tornare a quota 1000+ :cool:

[Kappaloris]

aggiunto WCG ma viene scaricato tutto nei criceti selvatici dato che non era presente prima.

[^Robbie^]

Per il discorso RAC potrebbe aver ragione il Capitano (quasi rabbrividisco :D ), forse parecchi pc sono spenti causa pausa estiva. Aspettiamo settembre

[Kappaloris]

Già, ed anche senza le classifiche che li giudicavano dall'alto, hanno fatto finta di nulla e lasciato il pc spento! Ma ora questo cambierà! Le classifiche sono tornate! MUahahahha.


:O

[ricky_4]

Già, ed anche senza le classifiche che li giudicavano dall'alto, hanno fatto finta di nulla e lasciato il pc spento! Ma ora questo cambierà! Le classifiche sono tornate! MUahahahha.


:O
aspetta che aggiunga il mio quad e dopo tremerete tutti :cool:

[Fornaciari]

aspetta che aggiunga il mio quad e dopo tremerete tutti :cool:
:paura::paura::paura::paura::paura::paura::paura:

:P:P:P:hahaha::hahaha::hahaha::hahaha::hahaha:

[Il Capitano]

Già, ed anche senza le classifiche che li giudicavano dall'alto, hanno fatto finta di nulla e lasciato il pc spento! Ma ora questo cambierà! Le classifiche sono tornate! MUahahahha.


:OIl Lato Oscuro forte in costui è

[RadioactiveToy]

aggiunto WCG ma viene scaricato tutto nei criceti selvatici dato che non era presente prima.
Con i 2000 di wcg sarei primo in classifica :sofico:

[RadioactiveToy]

Scusa K, ma i tag a cosa servono?

Ora provo :D

[RadioactiveToy]

Ok, capito :D

:spammone:

[ricky_4]

Ok, capito :D

:spammone:
maledetto eliminalo subito!!! :scared::scared:

[^Robbie^]

Ok, capito :D

:spammone:

Ottimo, capito anch'io :D

[Il Capitano]

Io ovviamente no :cool:

[RadioactiveToy]

maledetto eliminalo subito!!! :scared::scared:
Le verità non vanno occultate :O
Vedrai che prima o poi capirai e ti unirai a noi :P

Ottimo, capito anch'io :D
:re:

Io ovviamente no :cool:
E questo sarebbe il nostro vice ammiraglio? Siamo messi bene :D

[Fornaciari]

Le verità non vanno occultate :O
Vedrai che prima o poi capirai e ti unirai a noi :P

:re:

E questo sarebbe il nostro vice ammiraglio? Siamo messi bene :D


Non fare caso,lui è proprio così dalla nascita :D:asd:

[Il Capitano]

Non fare caso,lui è proprio così dalla nascita :D:asd:Pussa via tu, non svelare i miei segreti :O

[ricky_4]

Pussa via tu, non svelare i miei segreti :O
ah perchè son segreti? :sbonk:

[Il Capitano]

Ora che lo sapete, vi dovrò uccidere :O

[Kappaloris]

Approntata in nottata una gestione degli id rozza ma funzionante.

http://flottastellare.com/gestione.php

Le credenziali sono le stesse che avete per il forum.
Una volta loggati potrete aggiungere ID e monitorare quelli già vostri.
Ovviamente prevedo di aggiungerci molte cose (e di rendere il tutto un po' più appetibile graficamente) ma per ora c'è questo.

Vi prego di non smacellare troppo col nuovo db aggiungendo ID a muzzo. Controllate di aver inserito l'id corretto e di aver selezionato il progetto adeguato prima di premere 'Aggiungi'!

La pagina delle classifiche globali da ora in poi si aggiornerà ogni 15 minuti.

[ricky_4]

quad aggiunto e funzionante, ottimo lavoro kappa ;)

[RadioactiveToy]

Primo in classificaaaaaaaaaaaaaaa :first:


Continua così K :ave:

[Kappaloris]

Non per dire ma il sistema dello storico è su ed è funzionante. Registra lo status di ogni id per un anno con precisione giornaliera. Non male direi :D

[Dyd666]

Oddio spero di non dire fregnacce ma...perchè sul campo "Nome" della tabella viene visualizzata una svilza di caratteri , che non hanno nulla a che fare con il mio nickname?:stordita:

[Kappaloris]

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.

[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 :blah:

[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.