Ottimizzare una tabella di "amici"

[LuckySevenRoX]

Salve, ho una domanda che mi porto dietro da parecchio tempo alla quale devo dare una risposta.

Il progetto a cui sto lavorando ha la classica parte "social" dedicata agli amici, ovvero "chi" è amico di "chi".. e vorrei ottimizzare proprio questo punto o almeno capire qual'è la strada migliore da seguire in termini di "chiarezza", "pesantezza" e "velocità di recupero delle informazioni"

la prima strada è quella più "sempliciotta" dove nella tabella utenti (ID, nome, cognome ecc.) metto un altro campo "amici" al cui interno inserisco una stringa contenente i vari ID degli amici separati da qualche simbolo.. in questo caso non ho bisogno di fare altre tabelle, ma se uno si ritrova con 300-400 amici magari diventa confusionaria e lenta la situazione

la seconda ipotesi prevede una tabella "di mezzo" costituita principalmente da 2 campi che conterranno rispettivamente l'ID dell'utente e l'ID dell'amico. Di conseguenza, se un utente avrà 200 amici ci saranno 200 righe in quella tabella con il suo ID associato all'ID di ogni amico.

La seconda strada mi sembra ovviamente la migliore in termini di chiarezza, ma non so se è effettivamente la più veloce o la migliore da seguire. Suggerimenti?

[cris.calleo]

Io userei la tabella di mezzo.

[Emulman]

personalmente ritengo che la prima soluzione sia la migliore...se ad esempio hai un campo di tipo TEXT (non VARCHAR quindi) puoi mettere tanti ID separati da un simbolo tipo *, ad esempio 1*2*3*4*5 ; poi basta un comando $array = explode('*', $record['id_amici']; per avere un array con cui lavorare iN MEMORIA e quindi più veloce; nel secondo caso invece saresti nel caso di uan relazione mOLTI A MOLTI (un amico può avere più amici e viceversa) per cui appunto come giustamente fai rilevare occorre una tabella temporanea con unico ID utente ed un unico ID amico per avere una relazione UNO AD UNO. Ma così sicuramente si rallentano un pò le cose...cmq, dovresti fare una prova con tutti e due (ad esempio che leggano 100 amici) e controllare gli orari di inizio e fine script!

[cris.calleo]

Originariamente inviato da Emulman
personalmente ritengo che la prima soluzione sia la migliore...se ad esempio hai un campo di tipo TEXT (non VARCHAR quindi) puoi mettere tanti ID separati da un simbolo tipo *, ad esempio 1*2*3*4*5 ; poi basta un comando $array = explode('*', $record['id_amici']; per avere un array con cui lavorare iN MEMORIA e quindi più veloce; nel secondo caso invece saresti nel caso di uan relazione mOLTI A MOLTI (un amico può avere più amici e viceversa) per cui appunto come giustamente fai rilevare occorre una tabella temporanea con unico ID utente ed un unico ID amico per avere una relazione UNO AD UNO. Ma così sicuramente si rallentano un pò le cose...cmq, dovresti fare una prova con tutti e due (ad esempio che leggano 100 amici) e controllare gli orari di inizio e fine script!

Secondo me potrebbero esserci inconsistenze generate dal controllo duplicità dato che devi leggere un campo varchar.

[Emulman]

anche con la tabella temporanea sei costretto a fare lo stesso controllo e quindi con maggior perdita di tempo direi...

[cris.calleo]

Originariamente inviato da Emulman
anche con la tabella temporanea sei costretto a fare lo stesso controllo e quindi con maggior perdita di tempo direi...

Sai percaso come Facebook gestisce gli "amici"? mi pare che possono arrivare fino a 5.000.

[Emulman]

bella forza! li hanno web farms con migliaia di server sparsi in tutto il mondo, non hanno certo problemi di overload...se ne hai invece uno solo epr gestire 1000 utenti allora si che i problemi si fanno sentire!!!!

[Ranma2]

Per dati del genere orientati su nosql, solo per l'elenco degli amici intendo.

[satifal]

Originariamente inviato da LuckySevenRoX
La seconda strada mi sembra ovviamente la migliore in termini di chiarezza, ma non so se è effettivamente la più veloce o la migliore da seguire.

Le tabelle di relazione N a N servono proprio per situazioni del genere

[Longo8]

Allora tu hai una relazione ricorsiva molti:molti e quindi un'altra tabella che è la tabella di relazione dove ci saranno (principalmente) gli ID dell'utente che richiede l'amicizia e dell'utente che la accetta.