Devrais-je utiliser des types de publication personnalisés ou des tables de base de données personnalisées pour le développement de plug-in?

33

Je suis assez nouveau dans l'écriture de plugins wordpress, mais j'ai déjà sauté dans le vif du sujet et je veux m'assurer que je le fais "correctement" pour mon prochain grand projet.

Je vais strongment étendre wordpress dans une très grosse application web et je veux garder mes structures de données aussi natives que possible pour pouvoir compter sur le framework wordpress, mais je ne sais pas s'il est préférable de créer les miennes. tables de base de données personnalisées ou essayez d’utiliser des types de publication personnalisés.

Je ne connais pas encore toutes mes données, mais il y aura un certain nombre de tables (ou cpts) liées de manière relationnelle. Mes recherches me donnent l’impression que je devrais éviter les tables de base de données personnalisées, mais je ne sais pas comment déterminer la meilleure solution.

Plus précisément, je suis préoccupé par trois domaines:

  • le nombre de métafields post dont j'aurai besoin pour mes champs supplémentaires par cpt si j'emprunte cette route, et si cela rendra les choses "difficiles",
  • comment je peux récupérer les requêtes en utilisant des filtres relationnels semi-complexes pour les rapports
  • comment gérer au mieux les relations, surtout si j'ai plusieurs relations

Y a-t-il un "bon" chemin? Merci pour votre contribution.

    
posée Jeff 04.04.2012 - 01:16
la source

1 réponse

51

Vous devriez être sceptique à l’égard de quiconque affirmant qu’il existe un seul "droit" moyen. La bonne façon dépend de la situation. L’utilisation de l’infrastructure CPT présente un certain nombre d’avantages notables:

  • Vous obtenez gratuitement l'interface utilisateur du tableau de bord
  • Vous tirez automatiquement parti de la mise en cache de WP, y compris des plug-ins de cache persistant que l'installation peut utiliser
  • Vous obtenez automatiquement des friandises telles que les révisions postérieures
  • Vous avez accès à la classe WP_Query , ce qui signifie qu'en théorie, vous n'êtes pas obligé d'écrire (ou du moins pas beaucoup) de vraisemblable buggy, vulnérable et inefficace. SQL
  • Si vous envisagez de distribuer le plug-in ou de l'ouvrir pour un développement open source, vous constaterez peut-être que les développeurs sont plus à l'aise avec les types de publication personnalisés et les fonctions d'API associées que vos propres éléments personnalisés

Les problèmes avec l’API CPT proviennent principalement du fait qu’elle est très liée à la métaphore «posts» et à tous les aspects de ce type de données qui accompagnent la métaphore. A partir de la ligne de commande MySQL, exécutez DESCRIBE wp_posts . WP suppose que votre contenu a un titre, qu’il a un auteur (unique), qu’il vous suffit de garder trace de la date de création et de la date de dernière modification, que vous aurez besoin d’espace pour un post_content non indexé, etc. Cela fonctionne bien pour certains types de contenu, mais pas nécessairement pour d’autres. Vous avez déjà indiqué des problèmes potentiels:

  

le nombre de métafields post dont j'aurai besoin pour mes champs supplémentaires par cpt si j'emprunte cette route, et si cela rendra les choses "difficiles",

Il existe deux manières d'augmenter le schéma wp_posts via l'API CPT: postmeta et taxonomies. Postmeta est constitué de paires clé-valeur non indexées, ce qui est idéal pour stocker un tas de données diverses, mais pas du tout optimisé pour effectuer des recherches complexes. Les taxonomies sont un peu plus flexibles à cet égard, mais vous devrez faire face à de nombreuses sous-requêtes potentiellement coûteuses si vous avez des recherches très complexes. (Les arguments meta_query et tax_query et leurs classes de constructeur de requêtes sont très pratiques et pratiques, cependant.)

Si, comme vous le suggérez, vous seulement devez faire ce type de "filtres relationnels semi-complexes" dans le cas de rapports occasionnels, cette architecture vous convient probablement bien. C’est lorsque vous commencez à exposer les filtres aux utilisateurs, de sorte que vous devez exécuter de nombreux JOIN s complexes et sous-requêtes tout le temps, que les choses deviennent rapidement incontrôlables.

  

comment gérer au mieux les relations, en particulier si j'ai plusieurs relations

Les relations plusieurs à plusieurs sont un problème de longue date dans la communauté de développeurs WP (voir enlace ). Vous pouvez simuler sans utiliser de tables personnalisées en mappant des éléments de taxonomie sur post_ids (vous pouvez par exemple dire que "P3 a la relation Y à P5" en disant que P3 a la balise "Y-P3"), mais cela prête à confusion. (et inefficace) très rapidement. Vous pouvez également envisager de créer votre propre table de relations qui relie des CPT - vous bénéficierez toujours des CPT et ne créez qu'une seule table de base de données. Pour une version bien exécutée de cette méthode, voir le plug-in Posts 2 Posts: enlace

Donc, à la fin, vous devriez décider en fonction de:

  • Le (s) type (s) de données que vous allez stocker - comment "post" y at-il
  • Les types de requêtes qui seront nécessaires - quelle sera leur complexité
  • Échelle - quelle est la complexité du schéma souhaité, le nombre total d'objets que vous avez et le nombre d'utilisateurs que vous envisagez

Si les réponses sont les suivantes: très posty, pas trop complexe et ne devez pas évoluer à l’énorme hauteur, optez pour les TPC. Sinon, considérez vos propres tables.

    
réponse donnée Boone Gorges 04.04.2012 - 02:21
la source

Lire d'autres questions sur les étiquettes