Debe ser escéptico con cualquiera que diga que hay una única forma "correcta". La forma correcta depende de la situación. El uso de la infraestructura CPT tiene una serie de beneficios notables:
- Obtiene la interfaz de usuario del tablero de forma gratuita
- Aprovecha automáticamente el almacenamiento en caché de WP, incluidos los complementos de caché persistentes que la instalación pueda estar utilizando
- Obtendrá golosinas automáticamente como revisiones posteriores
- Obtiene acceso a la
WP_Queryclase, lo que significa que, en teoría, no tiene que escribir ningún SQL (o al menos no mucho) que sea probable que tenga errores y sea vulnerable e ineficiente.
- Si planea distribuir el complemento o abrirlo para el desarrollo de código abierto, es posible que los desarrolladores se sientan más cómodos con los tipos de publicaciones personalizadas y las funciones de API asociadas que con sus propias cosas personalizadas.
Los problemas con la API de CPT se deben principalmente al hecho de que está altamente casada con la metáfora de las 'publicaciones' y todos los aspectos de ese tipo de datos que vienen junto con la metáfora. Desde la línea de comando de MySQL, ejecute DESCRIBE wp_posts. WP asume que su contenido tiene un título, que tiene un (único) autor, que solo necesita hacer un seguimiento de la fecha de creación y la fecha de la última edición, que necesitará espacio para un índice no indexado post_content, etc. Esto funciona bueno para algunos tipos de contenido, pero no necesariamente para otros. Ya has señalado algunos problemas potenciales:
la cantidad de metacampos de publicación que necesitaré para mis campos adicionales por cpt si sigo esa ruta, y si eso hará que las cosas sean "difíciles"
Hay dos formas de aumentar el wp_postsesquema a través de la API de CPT: postmeta y taxonomías. Postmeta son pares clave-valor no indexados, lo cual es excelente para almacenar un montón de datos diversos, pero no está optimizado para realizar búsquedas complejas. Las taxonomías son algo más flexibles a este respecto, pero aún enfrentará muchas subconsultas potencialmente costosas si tiene búsquedas muy complejas. (Las meta_queryy tax_querylos argumentos y sus clases de consulta constructor son muy agradable y práctico, sin embargo.)
Si, como sugiere, solo necesita hacer este tipo de "filtros relacionales semi complejos" en el caso de informes ocasionales, entonces esta arquitectura probablemente sea adecuada para usted. Es cuando comienzas a exponer los filtros a los usuarios, de modo que tienes que ejecutar muchos JOINcorreos y subconsultas complejas todo el tiempo, que las cosas se salen de control rápidamente.
cómo manejar mejor las relaciones, especialmente si tengo muchas relaciones
Las relaciones de muchos a muchos son un punto de conflicto desde hace mucho tiempo en la comunidad de desarrollo de WP (consulte https://core.trac.wordpress.org/ticket/14513 ). Puede simularlo sin usar tablas personalizadas asignando elementos de taxonomía a post_ids (de modo que, por ejemplo, puede decir que 'P3 tiene la relación Y con P5' diciendo que P3 tiene la etiqueta 'Y-P3') pero esto se vuelve confuso (e ineficiente) muy rápidamente. También puede considerar crear su propia tabla de relaciones que vincule los CPT: aún obtendrá el beneficio de los CPT y solo creará una única tabla de base de datos. Para obtener una versión bien ejecutada de este método, consulte el complemento Posts 2 Posts: https://wordpress.org/extend/plugins/posts-to-posts/
Entonces, al final, debes decidir en base a:
- El tipo (s) de datos que almacenará, cómo se "publican" y
- Los tipos de consultas que se requerirán: cuán complejas serán
- Escala: cuán complejo es su esquema deseado, cuántos objetos totales tendrá y cuántos usuarios anticipa
Si las respuestas son: Muy elegante, no demasiado complejo, y no tiene que escalar súper enorme, vaya con CPT. De lo contrario, considere sus propias tablas.