Lors du développement de plugins nécessitant un stockage de données, quels sont les avantages et les inconvénients de l'utilisation d'une méthode ou d'une autre?
L' explication donnée dans le codex n'est pas détaillée:
Avant de vous lancer dans une toute nouvelle table, cependant, demandez-vous si le stockage des données de votre plugin dans Post Meta de WordPress (alias Champs personnalisés) fonctionnerait. Post Meta est la méthode préférée; utilisez-le lorsque cela est possible / pratique.
plugin-development
database
post-meta
Nassif Bourguig
la source
la source
Réponses:
Eh bien, si je prends le chapeau d'un gamin de script WP, ma réponse serait: utilisez toujours post_meta.
Cependant, je connais une ou deux choses sur les bases de données, donc ma réponse est: jamais, jamais, jamais, utilisez un EAV (aka la table post_meta) pour stocker des données que vous pourriez avoir besoin d'interroger.
Sur le front de l'index, il n'y en a fondamentalement aucun à utiliser dans les méta-tables. Donc, si vous stockez le type de données XYZ et espérez que vous interrogerez tous les messages qui ont XYZ avec une valeur de
'abc'
, eh bien ... bonne chance. (Voir tous les tickets liés aux utilisateurs / rôles / caps dans le WP trac pour vous donner une idée de la façon dont il peut être sanglant.)Sur le front de la jointure, vous tombez rapidement sur la limite à laquelle l'optimiseur décide d'utiliser un algorithme générique au lieu d'analyser la requête lorsqu'il existe plusieurs critères de jointure.
Ainsi, non, non, non, non. N'utilisez jamais, jamais, jamais une méta. Sauf si ce que vous stockez est cosmétique et ne fera jamais partie d'un critère de requête.
Il se décompose sur votre application. Si vous stockez, disons, la date de naissance d'un réalisateur de film, ce n'est pas grave. Utilisez une méta tout ce que vous voulez. Mais si vous stockez, disons, la date de sortie d'un film, vous ne devriez pas utiliser une table distincte (ou ajouter des colonnes à la table des publications) et ajouter un index à cette colonne.
la source
Si votre plugin va avoir BEAUCOUP de données, alors utiliser le
wp_postmeta
n'est PAS une bonne idée comme démontré ci-dessous:En prenant WooCommerce comme exemple, dans un magasin avec environ 30 000 produits, il y aura en moyenne environ 40 méta post (attributs et tout) par produit, 5 images de produit par produit, ce qui signifie qu'il y aura environ 4 méta d'image pour chaque image:
30 000 produits x 40 méta chacun = 1 200 000 lignes en
wp_postmeta
+
30 000 produits x 5 images chacun x 4 méta d'image pour chacun = 600 000 lignes en
wp_postmeta
Donc, avec seulement 30 000 produits, vous envisagez d'avoir 1 800 000 lignes
wp_postmeta
.Si vous ajoutez plus de propriétés à vos produits ou à vos images de produits, ce nombre se multipliera.
Le problème est double:
wp_postmeta
la table n'est pas indexée sauf si vous utilisez des versions ultérieures de mysql (c'est-à-dire pas d'index FULLTEXT pourmeta_value
)Pour donner un exemple à partir d'un cas réel:
Cela sélectionne la ville d'expédition de tous les détails de la commande à environ 3 secondes sur un serveur dédié d'entrée de gamme, même s'il y a 5 à 10 commandes . En effet, la requête est exécutée à partir d'une
wp_postmeta
table qui contient environ 3 millions de lignes dans l'installation en direct.Même la page d'accueil est assez lente, car le thème tire divers éléments de
wp_postmeta
- curseurs, quelques encarts de révision, quelques autres méta. En général, la liste des produits est très lente, les recherches sont également lentes lors de la liste des produits.Vous ne pouvez pas résoudre ce problème par tout moyen normal. Vous pouvez mettre Elastic Search sur votre serveur et utiliser un plugin Elastic Search dans Wordpress, vous pouvez utiliser redis / memcached, vous pouvez utiliser un bon plugin de cache de page, mais à la fin le problème fondamental restera - récupérer toute quantité de données à partir d'un ballonnement
wp_postmeta
la table sera lente, chaque fois que cela sera fait. Sur le serveur sur lequel j'ai testé la solution que j'ai implémentée ci-dessous, tous ces éléments ont été installés et configurés correctement et optimisés, et le site a fonctionné convenablement bien pour les utilisateurs non connectés ou les requêtes courantes depuis la mise en cache des plugins.Mais au moment où un utilisateur connecté a essayé de faire quelque chose qui n'était pas communément fait ou les crons, les plugins de mise en cache ou tout autre utilitaire ont voulu récupérer les données réelles de la base de données pour les mettre en cache ou faire autre chose, les choses se sont ralenties.
J'ai donc essayé autre chose:
J'ai codé un petit plugin pour prendre toutes les méta du produit (postmeta pour le produit de type post ) dans une table personnalisée générée par le code. Ce plugin a pris toutes les méta pour chaque publication et a créé un tableau en ajoutant chaque méta en colonnes et en insérant les valeurs dans chaque ligne. J'ai transformé le format EAV en un format relationnel horizontal et plat. J'ai également eu le plugin pour supprimer postmeta de tous les produits déplacés de la
wp_postmeta
table.Pendant que j'y suis, j'ai déplacé le postmeta des pièces jointes et tous les autres méta des types de messages vers leurs propres tables.
Ensuite, je me suis accroché au
get_(post_type)_meta
filtre pour remplacer la récupération des métadonnées pour les servir à partir de nouvelles tables personnalisées.Maintenant, la même requête que précédemment, qui prenait ~ 3 secondes à récupérer,
wp_postmeta
prend ~ 0,006 seconde. Le site se comporte désormais comme s'il s'agissait d'une nouvelle installation WP.....................
Naturellement, il est préférable de faire les choses à la manière de Wordpress. C'est en fait la norme.
Cependant , il est également évident que la table EAV est très inefficace dans la mise à l'échelle. Il est infiniment flexible et vous permet de stocker toutes les données, mais le prix que vous payez pour cela est la performance. C'est un compromis fondamental.
Dans ce contexte, il est difficile de dire à quelqu'un qui a l'intention d'avoir une tonne de données et - Dieu nous en préserve - de rechercher / rechercher sur ces données pour utiliser la
wp_postmeta
table à coup sûr. Le succès de performance sera formidable.L'utilisation de vos tableaux personnalisés permettra à vos données de s'accumuler et de rester suffisamment rapides.
Tout comme la façon dont Pippin Williams, le créateur du plugin Easy Digital Downloads, a indiqué qu'il utiliserait des tableaux personnalisés s'il commençait à coder son plugin, si vous allez créer quelque chose qui sera utilisé pendant longtemps ou accumuler beaucoup de données, il est plus efficace d'utiliser vos tableaux personnalisés si vous les concevez bien.
Vous devez vous assurer que tout autre développeur de plugin / addon a les moyens de se connecter à votre plugin pour manipuler vos données avant et après la récupération des données. Si vous faites cela, alors vous êtes assez solide.
la source
Cela dépend de ce que vous faites. La méthode WP consiste à utiliser les tables existantes, car elles ont été conçues pour être suffisamment flexibles, mais vous atteindrez parfois une nouvelle classe de données qui ne peut pas être placée dans une table existante, par exemple si vous vouliez des métadonnées de catégorie , vous pouvez choisir de créer une table wp_termsmeta.
Cependant, vous pouvez généralement stocker vos données assez confortablement dans les différentes tables existantes, et l'endroit où vous stockez vos données dépend de ce que fait votre plugin.
La mise en cache est implémentée dans WordPress pour accélérer également votre temps de réponse.
la source
d'accord avec denis 100%. Mais il existe un moyen de contourner cela.
Le problème avec l'utilisation de la méta post pour les valeurs à interroger est lorsque les valeurs sont des tableaux, etc.
Cela est stocké dans la base de données sous la forme d'une chaîne sérialisée, qui ressemblera à ceci:
Donc, lorsque vous souhaitez interroger tous les messages avec
array['key2'] = 'val 2'
wp, il faut extraire chaque entrée de méta appelée tableau, la décompresser, la tester, puis passer à la suivante. Cela fera définitivement tomber votre serveur si votre site est un succès et a beaucoup de publications, pages, publications personnalisées, etc.La solution dépend du projet et vous comprendrez pourquoi. Si vous deviez stocker les données sous forme de
var = val
fichier, alors wp pourra effectuer une recherche sans avoir php pour décompresser chaque test. Pour ce faire, dans le scénario ci-dessus, vous utiliseriez un espace de noms et stockeriez les méta-clés:alors wp recherchant la clé 2 avec val 2 pourra la retirer immédiatement. Cela dépend cependant du projet. Mon projet actuel repose sur environ 20 types de données différents à stocker avec chaque publication personnalisée, de sorte que ce qui précède ne ferait que créer un tableau massif à rechercher, vu comment nous attendons des centaines de milliers de publications. Donc, dans ce scénario, une table personnalisée est le seul moyen.
J'espère que cela aide quelqu'un
la source
Pour mon site FarmVille :) J'ai fait les deux mais je ne l'ai jamais fini car je l'ai vendu:
Je l'ai fait parce que je voulais d'une part que les utilisateurs modifient le site wordpress en entrant de nouvelles données farmville, par exemple "une vache coûte 10 pièces" MAIS du côté de l'intégration: SI un changement dans le xml ment la vache coûte maintenant "20 pièces" (via le plugin d'édition front-end) qui serait donné en option après: afin que soit le XML OU l'utilisateur ait raison (sorte de système wiki).
Voici donc un exemple d'utilisation des deux.
la source