Vous devriez vous méfier de quiconque affirmant qu'il existe un seul "bon" 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 de tous les plug-ins de cache persistant que l'installation peut utiliser.
- Vous obtenez automatiquement des goodies comme des révisions de post
- Vous avez accès à la
WP_Queryclasse, ce qui signifie qu'en théorie, vous n'avez pas à écrire de code SQL (ou du moins pas beaucoup) susceptible d'être bogué, vulnérable et inefficace.
- Si vous envisagez de distribuer le plug-in ou de l'ouvrir pour un développement à source ouverte, 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 liés à l'API CPT proviennent principalement du fait qu'il est très lié à la métaphore «posts» et à tous les aspects de ce type de données qui accompagnent la métaphore. À 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, qu'il vous faut de l'espace pour un non indexé post_content, 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 post-champs dont j'ai besoin pour mes champs supplémentaires par cpt si j'emprunte cette route, et si cela rend les choses "difficiles"
Il existe deux manières d'augmenter le wp_postsschéma 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 meta_queryet tax_queryarguments et leurs classes de constructeur de requêtes sont très agréable et pratique, cependant.)
Si, comme vous le suggérez, vous ne devez faire ce genre de « filtres relationnels semi - complexes » dans le cas des rapports occasionnels, cette architecture est probablement OK pour vous. C'est lorsque vous commencez à exposer les filtres aux utilisateurs, de sorte que vous devez exécuter de nombreux JOINsous-requêtes et s complexes à tout moment, que les choses deviennent rapidement incontrôlables.
Comment gérer au mieux les relations, surtout si j'ai plusieurs relations
Les relations plusieurs à plusieurs sont un point de blocage de longue date dans la communauté de développeurs WP (voir https://core.trac.wordpress.org/ticket/14513 ). 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 plugin Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Donc, à la fin, vous devriez décider en fonction de:
- Le type de données que vous allez stocker - comment "post" y sont-ils
- Les types de requêtes qui seront nécessaires - quelle sera leur complexité?
- Échelle - quelle est la complexité de votre schéma souhaité, combien d'objets totaux aurez-vous et combien d'utilisateurs envisagez-vous?
Si les réponses sont: très posty, pas trop complexe, et ne devez pas vous mesurer à une taille énorme, optez pour les CPT. Sinon, considérez vos propres tables.