Construction d'un plugin de promotion Wordpress évolutif - un tableau de valeurs méta sérialisées ou de nombreux méta-enregistrements

4

J'essaie de créer un plug-in de publication favori favori de Wordpress, qui soit évolutif et puisse gérer 1 000 ou 10 000 utilisateurs ou plus.

Il existe plusieurs approches différentes que j'ai observées dans d'autres plugins et j'aimerais savoir quelle serait la meilleure pratique en matière d'évolutivité, ce qui signifie que la taille de l'enregistrement ou le nombre d'enregistrements pourrait poser problème.

Problème: l’idée de base est qu’il existe un bouton sur un message dans lequel un utilisateur connecté peut cliquer pour le mettre en favori. Celui-ci doit ensuite être stocké dans la base de données pour que, lorsque l'utilisateur y accède, il ne puisse plus le mettre en favori et il peut également consulter la liste de ses publications favorites.

Option 1: Stockage dans les méta-tables utilisateur et post-méta avec des tableaux sérialisés

C’est ce que fait le système de publication de type Wordpress Post ( enlace ). Après le clic, le code récupère la clé méta _liked_posts de la table méta utilisateur qui stocke dans un tableau les identifiants de publication des publications que l'utilisateur a aimé et récupère la clé méta _user_likes de la table méta post qui stocke dans un tableau l'utilisateur identifiants des utilisateurs qui ont aimé le message.

Le code ajoute ensuite l'identifiant de publication actuel à _liked_posts et l'identifiant d'utilisateur actuel à _user_likes. Il incrémente également deux autres méta-enregistrements: post like like et un utilisateur like count.

Ce que j’aime dans ce système, c’est qu’il semble assez simple, avec un seul enregistrement dans la méta utilisateur et un autre dans le stockage post-méta qui a aimé quoi. Ce que je n’aime pas, c’est que si vous avez beaucoup d’utilisateurs qui aiment le message ou un utilisateur qui aime beaucoup de messages, ces tableaux de méta-valeurs peuvent être très longs, ce qui, je suppose, pourrait causer des problèmes?

$meta_POSTS = get_user_meta( $user_id, "_liked_posts" ); // post ids from user meta
$meta_USERS = get_post_meta( $post_id, "_user_liked" ); // user ids from post meta
$meta_POSTS['post-'.$post_id] = $post_id; // Add post id to user meta array
$meta_USERS['user-'.$user_id] = $user_id; // add user id to post meta array
update_post_meta( $post_id, "_user_liked", $meta_USERS ); // Add user ID to post meta
update_user_meta( $user_id, "_liked_posts", $meta_POSTS ); // Add post ID to user meta

Option 2: ajouter un enregistrement à la méta de l'utilisateur pour chaque publication préférée

Après le clic, le code vérifie si un enregistrement a déjà été inséré dans la méta de l'utilisateur. Sinon, il ajoute un nouvel enregistrement du favori. Si c'est le cas, cela ne fait rien.

Ce que j’aime dans ce système, c’est qu’il est facile d’interroger et de générer des statistiques plus tard, car il n’est pas encombré de tableaux sérialisés. Ce que je n’aime pas, c’est que si l’utilisateur aime beaucoup de messages, il est possible d’augmenter considérablement le nombre d’enregistrements dans la table méta.

// Check if already favourited the post in User Meta
// Not sure how you would do this with WP_Query or WP_User_Query, any suggestions?

$favourited = WP_Query($args)

if ($favourited->post_count == 0) {
  // Add user meta with favourite
  add_user_meta($userid, '_favourite_episode', $postid);
}

Pour conclure, je demande donc quelle est la meilleure pratique dans ce domaine. Est-ce soit:

  • Avoir un grand tableau sérialisé dans une seule paire méta clé / valeur
  • Avoir plusieurs paires méta / valeur de clé avec un entier dans la méta valeur
  • Existe-t-il une autre option que je n'ai pas envisagée?

MODIFIER: Suite aux réponses données, j'ai décidé que la création d'un tableau personnalisé était la meilleure voie à suivre. J'ai trouvé ce tutoriel qui fait à peu près ce que je veux faire et d'une manière bien plus extensible, de sorte que je puisse ajouter d'autres actions ainsi que simplement "favoriser".

enlace

    
posée Alex 03.04.2016 - 17:39

2 réponses

4

Vous avez oublié l'option 3 - Ajoutez une table spéciale dans laquelle la paire (utilisateur, identifiant de publication) sera l'index. Ok, je ne suis pas une personne de MySQL, donc c'est peut-être trop extrême, mais peut-être qu'avoir deux tables, l'une avec les utilisateurs comme index et l'autre avec les posts, sera encore meilleur.

En ce qui concerne les performances, il est rare qu’il y ait rarement des solutions absolues pour tout le monde, à tout moment, et le "meilleur" dépend de votre modèle d’utilisation, et non du modèle théorique. Ou, en d'autres termes, vous faites une optimisation précoce ici.

Bien que l'option 2 semble plus rapide pour ces informations spécifiques, elle augmentera la taille des tables de méta et risque donc de ralentir toutes les requêtes (la suggestion de l'option 3, qui est très similaire, mais n’a pas d’impact sur les autres requêtes).

Un autre problème que vous ignorez ici est le coût d’insertion / mise à jour des données. Cette opération est beaucoup plus lente qu'une lecture et ne peut pas être mise en cache. Si vous allez avoir plusieurs goûts en même temps, avec l'option 2, vous verrouillez les tables et les demandes doivent attendre que les autres soient terminées et chaque insertion sera plus lente, tandis que l'option 1 risque de corrompre les données avec une implémentation naïve. (deux changements en même temps, au mieux un seul aura un impact).

Ensuite, vous devez prendre en compte le type de mise en cache que vous allez effectuer. Avec un bon schéma de mise en cache, le temps de lecture n’est pas un problème.

Pour conclure, je souhaite que vous trouviez qu’il s’agissait d’un problème réel qui doit être résolu, d’ici là, écrivez simplement l’API appropriée pour accéder / modifier ces données afin de masquer les détails de la mise en œuvre. Ainsi, si cela devenait un problème, capable de modifier l'implémentation sans impacter le reste de votre code.

    
réponse donnée Mark Kaplun 03.04.2016 - 18:21
0

L'option 1 n'est pas le meilleur choix car la sérialisation des données signifie que vous devez analyser votre résultat SQL pour qu'il soit lisible. Vous ne pouvez donc tirer aucun avantage des requêtes SQL.

Option 2 serait le moyen le plus simple, mais si vous avez beaucoup d'utilisateurs qui aiment beaucoup de publications, cela commence à polluer la méta table des utilisateurs.

Option 3 Ce que je voudrais faire est de créer une table relationnelle entre les publications et les utilisateurs. Utiliser la table de relation serait la solution la plus simple car vous pouvez utiliser SQL pour effectuer beaucoup de logique à votre place. Par exemple, vous n'avez pas besoin de compter le nombre de mentions de J'aime dans une publication en PHP, mais d'exécuter une requête sur SQL qui le fait pour vous et renvoie le résultat. Cela signifie que les performances seront bonnes et que si vous désinstallez le plug-in, il ne vous reste plus qu'à supprimer le tableau, simplement et proprement.

    
réponse donnée Marttin Notta 03.04.2016 - 17:54

Lire d'autres questions sur les étiquettes