Je travaille actuellement sur un système d'évaluation PHP/MySQL. Pour que l'utilisateur puisse noter l'utilisateur doit se connecter. Chaque utilisateur a un "UID" unique. Il y aura plusieurs instances de notation sur le site (une pour chaque jeu, dans mon cas) et j'ai besoin d'un moyen efficace de stocker une liste d'UID dans une rangée MySQL (une ligne MySQL dans la table de notation pour chaque instance du système de notation) pour garder un décompte de qui a voté.Meilleure méthode pour stocker une liste d'ID utilisateur
J'ai vu dans d'autres systèmes que la liste est stockée dans un tableau PHP sérialisé. Chaque fois qu'un utilisateur vote, le tableau sérialisé doit être extrait, non sérialisé, le nouvel UID est inséré, le tableau est re-sérialisé et la ligne MySQL est UPDATEd. Chaque fois que la page est chargée, cette liste doit à nouveau être désérialisée et vérifiée pour voir si l'utilisateur consultant la page a déjà voté pour s'assurer que l'utilisateur ne votera pas deux fois.
Cela semble plutôt inefficace et lourd. Est-ce que MySQL a une fonction de liste intégrée pour aider ce processus à être plus efficace? Y at-il des moyens plus intelligents que je pourrais résoudre ce problème?
J'ai envisagé une alternative possible qui consiste à oublier la sérialisation et à stocker les UID dans un champ de type TEXT dans la base de données MySQL. Je voudrais juste ajouter un caractère non numérique après chaque UID (disons un point [.]). Pour ajouter une entrée d'utilisateur, je voudrais simplement concaténer l'UID à la fin du champ TEXT puis un point. En vérifiant si l'utilisateur a déjà voté je pourrais simplement "SELECT * FROM table WHERE votes = '% $ UID.%';". Est-ce que cela fonctionnerait plus efficacement ou y a-t-il une façon plus élégante de faire le travail?
poste de suivi de la structure de la table ... Efficient MySQL table structure for rating system
Il semble que vous et Mehrdad suggériez la même approche. Je le fais de cette façon. Ma seule préoccupation est la taille de la table VOTES. Il est concevable qu'il puisse y avoir des votes <# games x # users> dans cette table. Est-ce que cela devrait faire peur à mon administrateur de plan d'hébergement partagé? –
De manière réaliste, une taille de table doit atteindre des millions avant même que vous ayez besoin de considérer le «partitionnement» (la division des données essentiellement). L'approche de l'implosion d'un tableau aura des lignes mais des frais généraux significativement plus élevés pour la lecture et l'écriture. – cletus
Si vous faites les requêtes listées ci-dessus, assurez-vous d'indexer la table avec * à la fois * uid et gid pour accélérer les requêtes. C'est la plus grande pénalité de cette approche: vous avez besoin de plusieurs index. – slacy