Al desarrollar complementos que requieren almacenamiento de datos, ¿cuáles son las ventajas y desventajas de usar un método u otro?
La explicación de que figura en el códice no está detallada:
Antes de saltar con un nuevo todo tabla, sin embargo, considerar si el almacenamiento Los datos de tu plugin en WordPress 'Post Meta (a.k.a. Campos personalizados) sería trabajo. Post Meta es el preferido método; utilízalo cuando posible / práctico.
Bueno, si tomo el sombrero de un script de WP para niños, mi respuesta sería: usar post_meta, siempre.
Sin embargo, sé algo acerca de las bases de datos, así que mi respuesta es: nunca, nunca, nunca use un EAV (también conocido como la tabla post_meta) para almacenar datos que pueda necesitar consultar.
En el frente del índice, básicamente no hay ninguno que valga la pena utilizar en tablas meta. Entonces, si estás almacenando el tipo de datos XYZ y esperas que consultes todas las publicaciones que tienen XYZ con un valor de 'abc' , bueno ... buena suerte. (Vea todos los tickets relacionados con los usuarios / roles / gorras en el trac de WP para darle una idea de lo sangriento que puede ser).
En el frente de la combinación, rápidamente te topas con el límite en el que el optimizador decide usar un algoritmo genérico en lugar de analizar la consulta cuando hay varios criterios de combinación.
Por lo tanto, no, no, no, no. Nunca, nunca, nunca use un meta. A menos que lo que esté almacenando sea cosmético y nunca formará parte de un criterio de consulta.
Se descompone a su aplicación. Si está almacenando, digamos, la fecha de nacimiento de un director de cine, que gran cosa. Usa un meta todo lo que quieras. Pero si está almacenando, digamos, la fecha de lanzamiento de una película, estaría loco por no usar una tabla separada (o agregar columnas a la tabla de publicaciones) y agregar un índice a esa columna.
Si su complemento va a tener MUCHOS datos, entonces usar wp_postmeta NO es una buena idea como se muestra a continuación:
Tomando Woocommerce como ejemplo,
En una tienda con ~ 30,000 productos, digamos que habrá un promedio de ~ 40 post meta (atributos y todo) por producto, 5 imágenes de producto por producto, lo que significa que habrá ~ 4 meta de imagen para cada imagen:
30,000 productos x 40 meta cada uno = 1,200,000 filas en wp_postmeta
+
30,000 productos x 5 imágenes cada x 4 meta de imagen para cada = 600,000 filas en wp_postmeta
Por lo tanto, con solo 30,000 productos, está considerando tener 1,800,000 filas en wp_postmeta.
Si agrega más propiedades a sus productos o a las imágenes de sus productos, este número se multiplicará.
El problema con eso es doble:
Para dar un ejemplo de un caso real:
SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'
La consulta de, que selecciona la ciudad de envío de todos los detalles del pedido, llega a unos 3 segundos en un servidor dedicado de nivel de entrada, incluso si hay 5-10 pedidos . Esto se debe a que la consulta se ejecuta desde una tabla wp_postmeta que tiene ~ 3 millones de filas en la instalación en vivo.
Incluso la página de inicio es bastante lenta, ya que el tema extrae varios elementos de wp_postmeta: deslizadores, algunas inserciones de revisión, algunos otros meta. En general, la lista de productos es muy lenta, las búsquedas son igualmente lentas cuando se listan productos.
No puedes arreglar esto por ningún medio normal. Puede poner Elastic Search en su servidor y usar un complemento de Elastic Search en Wordpress, puede usar redis / memcached, puede usar un buen complemento de caché de página, pero al final quedará un problema fundamental: obtener cualquier cantidad de datos de una gran cantidad de datos. La tabla wp_postmeta será lenta, siempre que se haga. En el servidor donde probé la solución que implementé a continuación, todos estos se instalaron y configuraron correctamente y se optimizaron, y el sitio funcionó de manera aceptable para usuarios no registrados o consultas comunes desde que se activaron los complementos de almacenamiento en caché.
Pero en el momento en que un usuario que inició sesión intentaba hacer algo que no se hacía comúnmente o los crons, los complementos de almacenamiento en caché o cualquier otra utilidad querían obtener datos reales de db para almacenarlos en caché o hacer cualquier otra cosa, todo fue muy lento.
Así que intenté algo más:
Codifiqué un pequeño complemento para llevar todo el meta del producto (postmeta para producto de tipo de publicación) a una tabla personalizada generada por código. Este complemento tomó todos los metadatos para cada publicación y creó una tabla agregando cada meta como columnas e insertando los valores en cada fila. Entonces, convertí el formato EAV en un formato relacional horizontal y plano. También tuve el complemento para eliminar postmeta de todos los productos movidos de la tabla wp_postmeta.
Mientras estoy en eso, también moví el archivo adjunto postmeta y todos los metadatos del otro tipo de publicación a sus propias tablas.
Luego me conecté con get_ (post_type) _meta filter para anular la recuperación de metadatos para servirlos desde nuevas tablas personalizadas.
Ahora, la misma consulta de la anterior, que demoró ~ 3 segundos en recuperarse de wp_postmeta, tarda ~ 0.006 segundos. El sitio ahora se comporta como si fuera una instalación WP nueva.
....................
Naturalmente, hacer las cosas a la manera de WordPress es mejor. En realidad es la norma.
Sin embargo , también es obvio saber que la tabla EAV es muy ineficiente en la escala. Es infinitamente flexible y le permite almacenar cualquier información, pero el precio que paga por eso es el rendimiento. Es una compensación fundamental.
En ese contexto, es difícil decirle a alguien que tiene la intención de tener una tonelada de datos y, por supuesto, Dios no puede hacer preguntas / búsquedas en esos datos para usar la tabla wp_postmeta con seguridad. El éxito de rendimiento será grande.
El uso de sus tablas personalizadas permitirá que sus datos se acumulen y sigan siendo lo suficientemente rápidos.
Al igual que Pippin Williams, el creador del plugin Easy Digital Downloads, mencionó que usaría tablas personalizadas si estuviera comenzando a codificar su plugin, si va a crear algo que se usará durante mucho tiempo o se amontonará. de datos, es más eficiente usar sus tablas personalizadas si las diseña bien.
Debe asegurarse de que cualquier otro desarrollador de complementos / complementos tenga medios para conectarse a su complemento para manipular sus datos antes y después de la recuperación de los datos. Si haces eso, entonces eres bastante sólido.
Depende de lo que estés haciendo. La forma WP es usar las tablas existentes, ya que han sido diseñadas para ser lo suficientemente flexibles, sin embargo, en ocasiones, llegará a una nueva clase de datos que no se pueden colocar en una tabla existente, por ejemplo. Si desea metadatos de categoría, puede elegir crear una tabla wp_termsmeta.
Sin embargo, por lo general, puede almacenar sus datos de manera muy cómoda en las diferentes tablas que existen, y el lugar donde almacena sus datos depende de lo que haga su complemento.
El almacenamiento en caché se implementa dentro de WordPress para acelerar el tiempo de respuesta también.
de acuerdo con denis 100%. Pero hay una manera de evitarlo.
El problema con el uso de la meta meta para los valores que se deben corregir es cuando los valores son de matriz, etc. Por ejemplo:
array(
'key1' => 'val 1',
'key2' => 'val 2'
);
Esto se almacena en la base de datos como una cadena serializada, que se verá así:
{array["key1"]...{}...}
Entonces, cuando desee consultar todas las publicaciones con array['key2'] = 'val 2' , entonces wp tiene que extraer cada entrada meta llamada array, descomprimirla, luego probarla y luego pasar a la siguiente. Esto definitivamente derribará su servidor si su sitio tiene éxito y tiene muchas publicaciones, páginas, publicaciones personalizadas, etc.
La solución depende del proyecto, y verás por qué. Si almacenara los datos como var = val , entonces wp podrá buscar sin tener php para descomprimir cada prueba individual. Para hacer esto en el escenario anterior, usaría algo de espacio de nombres y almacenaría las claves de metadatos:
_array_key1 = 'val 1';
_array_key2 = 'val 2';
entonces wp buscando la clave 2 con val 2 podrá tirar de ella inmediatamente. Este es un proyecto dependiendo. Mi proyecto actual se basa en unos 20 dataTypes diferentes para ser Almacene con cada publicación personalizada, por lo que lo anterior solo creará una tabla masiva para buscar, ya que esperamos que haya cientos de miles de publicaciones. Entonces, en ese escenario, una tabla personalizada es la única manera.
Espero que esto ayude a alguien
Para mi sitio de FarmVille :) Hice ambas cosas pero nunca las terminé porque las vendí:
Hice esto porque quería, por un lado, que los usuarios editaran el sitio de wordpress ingresando nuevos datos de farmville, por ejemplo. "una vaca cuesta 10 monedas" PERO desde el lado de la integración: si se trata de un cambio en el xml, la vaca ahora cuesta "20 monedas" (a través del complemento de edición de front-end) que se daría como una opción después de eso: para que XML O el usuario tenía razón (tipo de sistema wiki).
Así que aquí hay un ejemplo cuando se usan ambos.
Lea otras preguntas en las etiquetas plugin-development database post-meta