MySQL - Registrazione voti utente

[zoc]

Ciao a tutti.
Sto facendo un sistema di votazione e sto cercando di capire cosa e' piu' performante per la registrazione dei voti.
Ipotesi 1: fare una tabella con id_utente, post_id, voto
Ipotesi 2: registrare per ogni utente un unico campo in cui si inserisce un array serializzato con struttura:

array(

   post_id => voto
   post_id => voto
   post_id => voto
   post_id => voto
   post_id => voto

)

Fare la tabella mi fa paura perche' il numero di record potrebbe veramente diventare enorme. E ogni volta fare una query in una tabella cosi' grossa mi fa venire paura in quanto a prestazioni.

Ma l'altra ipotesi, quella dell'unico campo con all'interno l'array serializzato, mi fa paura lo stesso perche' ho paura di arrivare a un punto in cui l'array scoppia!

help!! grazie mille!

[bomberdini]

Ciao a tutti.
Fare la tabella mi fa paura perche' il numero di record potrebbe veramente diventare enorme.

di quanti record parliamo?

considera che ci sono tecniche come il partizionamento...

[optime]

niente è più soggettivo dell'aggettivo ("enorme" nel caso)

[Fede_91]

Ciao, secondo me dovresti creare la tabella con i 3 campi che hai indicato così avrai anche la possibilità di filtrare per id_utente e post_id, trovare il numero di voti che ha fatto in totale un utente, ecc...Per quanto riguarda le performance, potresti valutare la creazione degli indici sulle colonne che userai di più e, se prevedi milioni di record potresti provare anche il partizionamento della tabella..

F.

[zoc]

Ciao ragazzi,
grazie per l'aiuto... vado a pensare a voce alta cosi nel caso mi potete bacchettare.

Devo fare le cose da buon progettista.
Fare in partenza progetto una tabella partizionata complicherebbe di tanto la realizzazione? Forse si...
Partizionarla orizzontale secondo data? id?
Dopo quanti voti sarebbe consigliabile partizionare una tabella? Giustamente come dice Optime cosa e' enorme?
Inoltre se le query che si fanno front end non sono create per lavorare sulla tabella partizionata non c'e' beneficio...
Se partissi con una tabella normale, dovrei fare le cose in modo tale da permettere un ampliamento futuro ( appunto la partizione della tabella )... chissa' se ci sono delle best practice da seguire, per evitare di trovarsi davanti a un muro nell'ampliamento del progetto.

Quindi pensando di partire con una tabella senza partizionamento, passo a riflettere sulla possibilita' di aggiungere degli indici. Per ora la struttura e':
ID, utente_id, post_id, voto
La chiave primaria ID probabilmente e' superflua... posso pensare di eliminarla e fare diventare INDEX sia utente_id che post_id cosi' da velocizzare le query...

grazie per ogni consiglio che arrivera'!

[Fede_91]

Ciao, secondo me avrebbe senso partizionare la tabella subito solo se sei sicuro se questa conterrà decine di milioni di record (io lo farei su un range di post_id o utente_id.. dipende come devi usare le informazioni ).
Se, per il momento, voi iniziale con una tabella senza partizionamento, la via degli indici che hai indicato, imho, è quella giusta.

F.

[zoc]

ok grazie.
Penso che sia meglio partire a tabella singola con gli indici che abbiamo detto.
Un consiglio pero' ... c'e' qualche cosa che devo fare o a cui devo stare attendo per evitare di avere problemi una volta che, forse, in futuro, decidero' di partizionare la tabella?

grazie ancora!

[bomberdini]

per non avere effetti controproducenti ricordati di creare gli indici solo sui campi in cui ha senso crearli... non su tutti

[zoc]

Ciao Bomberdini,

ha senso creare un indice quando verranno fatte delle query del tipo "WHERE campo_indice .... ",
giusto? ... oppure si fanno anche in visione di altro che non so...

grazie...

[Fede_91]

Per il momento puoi creare gli indici solo sulle colonne che ti servono nelle query.. In futuro ne potrai creare altri in base alle esigenze

F.