¿Debo usar tipos de publicaciones personalizados o tablas de bases de datos personalizadas para el desarrollo de complementos?

33

Soy bastante nuevo en escribir plugins de WordPress, pero ya me he metido en la parte más profunda y quiero asegurarme de que lo estoy haciendo "bien" en mi próximo gran proyecto.

Estaré extendiendo Wordpress en gran medida en una aplicación web bastante grande y quiero mantener mis estructuras de datos lo más nativas posible para confiar en el marco de WordPress, pero no sé si es mejor crear mi propia tablas de bases de datos personalizadas o intente hacer uso de tipos de publicaciones personalizados.

Todavía no conozco todos mis datos, pero habrá una serie de tablas (o cpts) vinculadas de manera relacional. En mi investigación, obtengo la "vibra" de que debo evitar las tablas de bases de datos personalizadas, pero no estoy seguro de cómo determinar la mejor solución.

Específicamente me preocupan tres áreas:

  • el número de campos de metraje posteriores que necesitaré para mis campos adicionales por cpt si voy por esa ruta, y si eso hace que las cosas sean "complicadas"
  • qué tan bien puedo volver a las consultas usando filtros relacionales semi complejos para los informes
  • cómo administrar mejor las relaciones, especialmente si tengo muchas o muchas relaciones

¿Hay una manera "correcta"? Gracias por tu aporte.

    
pregunta Jeff 04.04.2012 - 01:16

1 respuesta

51

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.

    
respondido por el Boone Gorges 04.04.2012 - 02:21

Lea otras preguntas en las etiquetas