Bonsoir.

Je viens encore vous embêter mais cette fois ci c'est pour un soucis d'ordre théorique. J'aimerais réaliser un système d'amis sur un projet de sorte que seuls les amis puissent consulter le fil d'actualité d'un membre.

Par exemple j'ai réalisé une timeline qui retrace toutes les actions d'un membre (si le membre modifie son profil, poste une nouvelle photo dans sa gallerie etc). Et j'aimerais que ce fil d'actualité ne soit affichage que pour les amis de l'utilisateur.

Pour créer les amis je pensais simplement créer une table "friends" du type

friend_id
friend_applicant // celui qui fait la demande
friend_receiver // celui qui reçoit la demande
friend_statut // TRUE or FALSE
friend_created // Date de demande
friend_updated // Date d'acceptation

Déjà je doute de l'efficacité de ce système pour stocker les amis quand le site aura mettons 100 membres et que tous ses membres seront amis entre eux (par exemple).

Puis je pense que le système serait assez lourd lorsque je récupérerais le contenu, je devrais faire une liaison entre ma table contenu et la table amis pour vérifier si le membre est ami et s'il a le droit, du coup, de voir cet élément de la timeline.

J'espère que j'ai réussi à me faire comprendre ^^
Enfin soit, j'aimerais juste avoir votre avis pour savoir si la voie que je compte prendre est bonne ou si il vaudrait mieux en changer, et si tel est le cas, par quoi ?

Merci, bien à vous

Non tu n'as pas vraiment le choix, essaie simplement d'éviter au maximum les champs 'inutiles', du style 'date de demande d'acceptation'. C'est tres rarement une donnée que tu utiliseras mais qui sera stockée 100% du temps. Ce sont ces choses là qui alourdissent beaucoup un site.

Par contre je ne comprends pas bien l'utilité de friends_id ?

Tu as déjà friends_applicant/receiver, friends_id serait l'id de 'l'amitié' en question ?

La solution miracle : le cache.

Peu importe la structure de ta table, il te suffit ensuite de cacher les amis de chaque utilisateur. Dans ta table users par exemple, tu rajoutes un champ de type text qui s'appellera par exemple friends_cache. Dans ce champ tu stockes les ID de tous les amis de ton user (avec un tableau sérialisé, ou tout bêtement une liste d'ID séparées par des virgules). Ainsi tu pourras avoir facilement accès à la liste des amis d'un user sans pour autant devoir interroger ta table d'amis en permanence. Il te suffit de mettre à jour cette liste en cache lorsque tu ajoutes / supprimes un ami.

La solution miracle : le cache.

Peu importe la structure de ta table, il te suffit ensuite de cacher les amis de chaque utilisateur. Dans ta table users par exemple, tu rajoutes un champ de type text qui s'appellera par exemple friends_cache. Dans ce champ tu stockes les ID de tous les amis de ton user (avec un tableau sérialisé, ou tout bêtement une liste d'ID séparées par des virgules). Ainsi tu pourras avoir facilement accès à la liste des amis d'un user sans pour autant devoir interroger ta table d'amis en permanence. Il te suffit de mettre à jour cette liste en cache lorsque tu ajoutes / supprimes un ami.

C'est pas bête en effet et beaucoup plus léger, je vais tenter ça

Merci bien

Pourquoi appeler ça "en cache" Genova ? Tu peux développer, ou si tu as des liens qui parlent un peu de ça ?

Pour le tableau sérialisé, dans la BDD ? Ca a ses limites non ?

Pourquoi appeler ça "en cache" Genova ? Tu peux développer, ou si tu as des liens qui parlent un peu de ça ?

Pour le tableau sérialisé, dans la BDD ? Ca a ses limites non ?

Cacher quelque chose en informatique (cacher = action de mettre en cache, et non pas "planquer"), c'est sauvegarder le résultat d'un calcul qui peut être long à charger, afin de l'afficher instantanément au second coup.

Par exemple imaginons que tu veuilles afficher le nombre total de membres inscrits sur ton site. La solution standard serait de faire une requête SQL pour compter tes membres en base de donnée (SELECT COUNT(*) FROM users) et d'afficher ensuite le résultat.
Tu peux accélérer cette action en stockant le résultat dans un endroit plus rapide d'accès (par exemple en utilisant Redis pour le stocker directement dans la RAM du serveur), ce qui fait que la prochaine fois tu n'as plus besoin de faire une requête SQL, ce qui évite d'engorger MySQL si tu as trop de visiteurs. Des membres qui s'inscrivent, à priori tu n'en as pas à chaque seconde. Donc il est inutile d'aller interroger à chaque fois ta base de donnée pour connaître ce nombre, il te suffit de le stocker, et de le mettre à jour seulement quand un nouveau membre s'inscrit.
L'exemple n'est pas le meilleur, puisque faire un SELECT COUNT(*) est extrêmement rapide, mais le principe est là : chercher à gagner du temps en lecture.

Par rapport à la liste d'amis, il est inutile d'aller demander à la base de donnée à chaque fois "qui sont mes amis ?", puisque la liste d'amis varie assez peu (à moins d'être le pape ou une très grosse célébrité ). Plutôt donc d'effectuer ce traitement couteux à chaque fois, on le fait juste une seule fois, on stock cette liste dans un endroit rapide d'accès (un simple champ donc), et on le met à jour simplement lorsqu'un nouvel ami arrive. Il n'y a aucun problème à sérialiser ces données et les mettre dans un champ TEXT. Un champ TEXT peut contenir jusqu'à 65K caractères, donc tu as le temps de voir venir.

Cacher des données c'est la technique numéro 1 pour optimiser un site. C'est omniprésent sur tous les sites à fort traffic, et cela à tous les niveaux. Le sujet est trop vaste pour pouvoir être développé convenablement ici, mais tu trouveras facilement ton bonheur sur google. Au final c'est surtout une façon de procéder : comment faire en sorte que mes pages s'affichent le plus rapidement possible, et en consommant le moins possible de ressources sur mon serveur.