Debería ser escéptico ante cualquiera que diga que existe una única forma "correcta". El camino correcto depende de la situación. El uso de la infraestructura CPT tiene varios beneficios notables:
- Obtienes la interfaz de usuario del panel de forma gratuita
- Usted se aprovecha automáticamente del almacenamiento en caché de WP, incluidos los complementos de caché persistentes que la instalación pueda estar usando
- Obtienes golosinas automáticamente como revisiones de publicaciones
- Obtienes acceso a la clase
WP_Query , lo que significa que, en teoría, no tienes que escribir ninguna (o al menos no mucho) la posibilidad de que sea un buggy y una persona vulnerable e ineficiente SQL
- 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 utilizando los tipos de publicaciones personalizados y las funciones de la API asociadas que sus propias cosas personalizadas.
Los problemas con la API de CPT provienen principalmente del hecho de que está altamente relacionado con la metáfora de "publicaciones" y con todos los aspectos de ese tipo de datos que vienen junto con la metáfora. Desde la línea de comandos de MySQL, ejecute DESCRIBE wp_posts . WP asume que su contenido tiene un título, que tiene un autor (único), que solo necesita realizar un seguimiento de la fecha de creación y la fecha de la última edición, que necesitará espacio para un post_content no indexado, etc. Esto funciona bien para algunos tipos de contenido, pero no necesariamente para otros. Ya has hecho un gesto hacia la dirección de algunos problemas potenciales:
la cantidad de campos de meta que necesitaré para mis campos adicionales por cpt si voy por esa ruta, y si eso hace las cosas "difíciles"
Hay dos formas de aumentar el esquema wp_posts a través de la API de CPT: postmeta y taxonomías. Postmeta es un par de clave-valor no indexado, lo cual es ideal para almacenar una gran cantidad de datos variados, pero no está optimizado en absoluto 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. (Sin embargo, los argumentos meta_query y tax_query y sus clases de constructor de consultas son muy agradables y útiles).
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 empiezas a exponer los filtros a los usuarios, de modo que tienes que ejecutar muchos JOIN s y subconsultas todo el tiempo, que las cosas se salen de las manos rápidamente.
cómo administrar mejor las relaciones, especialmente si tengo muchas o muchas relaciones
Las relaciones de muchos a muchos son un punto de conflicto desde hace mucho tiempo en la comunidad de desarrolladores de WP (consulte enlace ). Puede falsificarlo sin utilizar 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ápido. También puede considerar la posibilidad de crear su propia tabla de relaciones que vincule los CPT; aún así obtendrá el beneficio de los CPT y solo creará una única tabla de base de datos. Para una versión bien ejecutada de este método, vea el complemento de Publicaciones 2 Publicaciones: enlace
Entonces, al final, deberías decidir en función de:
- El tipo (s) de datos que almacenará: cómo "publican" y están
- Los tipos de consultas que se requerirán, qué tan complejas serán.
- Escala: cuán complejo es su esquema deseado, cuántos objetos tendrá en total y cuántos usuarios anticipa
Si las respuestas son: muy posty, no demasiado complejas, y no tienen que escalar super-enormes, vaya con CPTs. De lo contrario, considera tus propias tablas.