Originariamente inviato da daniele_dll
Ciao,
anche se il progetto è interessante, da una veloce occhiata che ho dato non mi sembra scritto molto bene, anzi:
- codice html mischiato con codice php, il che significa che la personalizzazione a livello grafico è esclusivamente relativa ai CSS;
- usi le sessioni di php che oltre ad essere lente sono insicure in quanto stanno su file e nel 99.99% dei casi sono condivise con gli altri siti web dell'hoster;
- fai un sacco di query ma non liberi mai le risorse utilizzate, cosa che comporta che le pagine terranno occupata la memoria, inutilmente, fino alla fine dell'esecuzione;
- nelle pagine che ho guardato, il codice iniziale è uguale in tutte il che significa che correggere un bug diventa più difficoltoso perché la correzione la devi replicare ovunque con il rischio che te ne scordi una ... vai a vederlo poi
;
- non ci sono controlli sugli errori della connessione al database;
- le query potrebbero essere ottimizzate dato che in alcuni casi si potrebbe accorpare il codice per risparmiare parecchio lavoro a mysql;
- non fai controlli sui parametri in ingresso (mysql_real_escape_string), il che significa che le query possono essere modificate e se per caso è pure spento il magic_quote_gpc diviene una strage vera e propria;
Ci sono altre piccole cose, ma non sono più rilevanti di tanto, anche perché il tutto fin qui è relativo solo al codice, il database ha anche i suoi problemi:
- TUTTI i valori numerici, escluso un indice, ovvero la tabella cmsg, non sono unsigned il che significa che stai buttando metà degli indici e metà dei valori utilizzabili per gli altri campi che non avranno mai valori negativi (dipende dal loro utilizzo, ovviamente i campi che possono avere valori negativi devono essere signed);
- INT arriva massimo a 10 cifre ed il 10, comunque, è utilizzato ESCLUSIVAMENTE per la visualizzazione del valore (in pratica ci mette degli spazi quando lo restituisce o degli zero se si usa zerofill ^^) ma non limita il range e questo vale anche per gli altri tipi numerici (
http://dev.mysql.com/doc/refman/4.1/...ric-types.html ) ... ho visto che in svariate tabelle metti valori superiori al 10 o inferiori al 10 il che significa che praticamente quasi tutti gli INT andrebbero cambiati in altri tipi anche se c'è da considerare che INT arriva a 4 miliardi errotti che è un valore più che sufficiente per il 99.99% dei casi
- fai un uso misto di campi timestamp o campi numerici per tenere lo unix timestamp (last_update con INT 20 ... dovresti usare un BIGINT 20 ma ritengo che 4 miliardi per lo unix timestamp siano più che sufficienti dato che il timestamp attuale è 1278596430 e come puoi vedere deve salire ancora parecchio prima di raggiungere i 4 miliardi errotti di un INT UNSIGNED)
- alla tabella delle news manca la chiave primaria, e va messa, ed il testo della news è di tipo TINYTEXT che riesce a contenere massimo 255 caratteri che mi sembrano un pò pochini per delle news ... un campo di tipo TEXT già tiene 64kb e dovrebbero essere più che sufficienti
- dovresti rivedere i nomi dei campi perché guardando le tabelle non si capisce molto
Il mio consiglio è di rivedere tutte queste cose perché altrimenti rischi che diventino MOLTO più complicate da sistemare più avanti. E, per finire, se poi riscrivi tutto a oggetti ed implementi un sistema di caching basato su memcache/apc/xcache sarebbe ottimo perché eviteresti di lanciare una marea di query ad ogni accesso dell'utente
