Je construis une fonctionnalité de mise en favori, permettant aux utilisateurs de placer un marqueur dans un article de blog. Les données seront ensuite enregistrées dans la base de données et récupérées lors de l'ouverture de cet article de blog.
Le même concept peut être appliqué à beaucoup de choses dans WordPress, comme les notes, les favoris, etc. Jusqu'à présent, j'ai créé de nouveaux tableaux MySQL (approche 2) pour ces fonctionnalités, mais maintenant, je me pose des questions.
Les deux options d’approche:
wp_usermeta
Cela nécessiterait de sérialiser une liste d'ID de publication et de positions de marqueur, puis de les stocker dans la table wp_usermeta
en tant que chaîne. L'utilisation de cette méthode semble la plus simple, mais je ne suis pas certain de l'impact que cela pourrait avoir sur les performances de la table wp_usermeta
. En particulier, les données sérialisées pourraient être potentiellement volumineuses.
Avec cette option, je n'aurais pas besoin de sérialiser les données, mais chaque nouveau marqueur obtiendrait sa propre ligne, qui devrait contenir les noms user_id, post_id et peut-être un horodatage.
J'aimerais savoir laquelle de ces méthodes est préférée, en tenant compte d'éléments tels que les performances, l'évolutivité, la compatibilité et la facilité d'utilisation. Ou peut-être il y a une meilleure méthode que ces deux?
La normalisation des données est plus efficace et le stockage de données sérialisées dans un champ de table que vous souhaitez rechercher/utiliser au niveau de la base de données ne convient pas au SGBDR non-Nosql comme MySQL/MariaDB. La recherche dans ces champs est inefficace, vous ne pouvez pas utiliser d'index, ni y joindre, et il est généralement pénible de développer un imho. Si vous avez stocké ces données dans un objet blob sérialisé PHP, vous devrez charger chaque ligne pour pouvoir l'examiner, car la base de données ne peut pas vous aider (ou écrire des expressions rationnelles très laides). , cela peut exploser si quelqu'un a le goût d'ajouter d'autres données à ce champ).
Cela dit, à moins que vous ne disposiez de plus grandes quantités de données, vous ne ressentirez probablement pas l'inefficacité en secondes d'horloge sur des requêtes simples, et il serait peut-être plus facile de travailler avec des méta-champs utilisateur qui en sera responsable une fois que vous l'avez livrée) sont avec des bases de données.