Post meta vs tablas separadas en la base de datos

Si tu plugin va a manejar MUCHOS datos, entonces usar la tabla wp_postmeta NO es una buena idea, como se demuestra a continuación:

Tomando WooCommerce como ejemplo, en una tienda con ~30,000 productos, habrá un promedio de, digamos, ~40 metadatos por producto (atributos y todo), 5 imágenes por producto, lo que significa que habrá ~4 metadatos por cada imagen:

30,000 productos x 40 metadatos cada uno = 1,200,000 filas en wp_postmeta

+

30,000 productos x 5 imágenes cada uno x 4 metadatos por imagen = 600,000 filas en wp_postmeta

Así que con apenas 30,000 productos, estarás manejando 1,800,000 filas en wp_postmeta.

Si agregas más propiedades a tus productos o a las imágenes de tus productos, este número se multiplicará.

El problema con esto es doble:

• Los self joins son muy costosos en MySQL
• La tabla wp_postmeta no está indexada a menos que uses versiones recientes de MySQL (es decir, no hay índice FULLTEXT para meta_value)

Para dar un ejemplo de un caso real:

SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'

Esta consulta, que selecciona la ciudad de envío de todos los detalles de pedidos, tarda ~3 segundos en un servidor dedicado de nivel básico, incluso si solo hay 5-10 pedidos. Esto se debe a que la consulta se ejecuta en una tabla wp_postmeta que tiene ~3 millones de filas en la instalación en producción.

Incluso la página de inicio carga bastante lento, porque el tema extrae varios elementos de wp_postmeta: sliders, algunas reseñas, algunos otros metadatos. En general, la lista de productos es muy lenta, y las búsquedas son igualmente lentas al listar productos.

No puedes solucionar esto mediante métodos normales. Puedes instalar Elastic Search en tu servidor y usar un plugin de Elastic Search en WordPress, puedes usar redis/memcached, puedes usar un buen plugin de caché de páginas, pero al final el problema fundamental permanecerá: recuperar cualquier cantidad de datos de una tabla wp_postmeta inflada será lento, sin importar cuándo se haga. En el servidor donde probé la solución que implementé a continuación, todos estos estaban instalados, configurados y optimizados correctamente, y el sitio funcionaba aceptablemente bien para usuarios no logueados o consultas comunes, ya que los plugins de caché entraban en acción.

Pero en el momento en que un usuario logueado intentaba hacer algo no común o los crons, plugins de caché o cualquier otra utilidad necesitaba recuperar datos reales de la base de datos para almacenarlos en caché o hacer cualquier otra cosa, todo se volvía extremadamente lento.

Así que probé algo diferente:

Programé un pequeño plugin para llevar todos los metadatos de productos (postmeta para el tipo de publicación product) a una tabla personalizada generada por código. Este plugin tomaba todos los metadatos de cada publicación y creaba una tabla añadiendo cada metadato como columnas e insertando los valores en cada fila. Convertí el formato EAV en un formato relacional plano y horizontal. También hice que el plugin eliminara los postmeta de todos los productos movidos de la tabla wp_postmeta.

Mientras lo hacía, también moví los metadatos de attachment y los metadatos de otros tipos de publicación a sus propias tablas.

Luego, enganché el filtro get_(post_type)_meta para anular la recuperación de metadatos y servirlos desde las nuevas tablas personalizadas.

Ahora la misma consulta de antes, que tardaba ~3 segundos en recuperar datos de wp_postmeta, tarda ~0.006 segundos. El sitio ahora se comporta como si fuera una instalación fresca de WordPress.

....................

Naturalmente, hacer las cosas al estilo de WordPress es mejor. De hecho, es la norma.

Sin embargo, también es un conocimiento obvio que una tabla EAV es muy ineficiente para escalar. Es infinitamente flexible y te permite almacenar cualquier dato, pero el precio que pagas por eso es el rendimiento. Es una compensación fundamental.

En ese contexto, es difícil decirle a alguien que planea manejar una gran cantidad de datos y —Dios no lo quiera— consultar/buscar en esos datos que use la tabla wp_postmeta con seguridad. El impacto en el rendimiento será enorme.

Usar tus propias tablas personalizadas permitirá que tus datos se acumulen y aún así 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 hoy, si vas a crear algo que se usará durante mucho tiempo o acumulará muchos datos, es más eficiente usar tus propias tablas si las diseñas bien.

Debes asegurarte de que cualquier otro desarrollador de plugins/addons tenga medios para engancharse a tu plugin y manipular tus datos antes y después de su recuperación. Si haces eso, entonces estarás bastante sólido.

Depende de lo que estés haciendo. La forma de WP es utilizar las tablas existentes, ya que han sido diseñadas para ser lo suficientemente flexibles, sin embargo ocasionalmente podrías encontrarte con una nueva clase de datos que no puede ser colocada en una tabla existente, por ejemplo, si quisieras metadatos para categorías, podrías elegir crear una tabla wp_termsmeta.

Sin embargo, usualmente puedes almacenar tus datos cómodamente en las diferentes tablas que existen, y dónde almacenes tus datos depende de lo que haga tu plugin.

• Para configuraciones generales del plugin, usa la llamada API get_option() - esto también será cacheado.
• Para configuraciones del plugin que sean particulares a un post individual, entonces usa los metadatos personalizados por post con get_post_meta(). Esto usualmente es suficiente para lo que necesitas.

El caché está implementado dentro de WordPress para acelerar también tu tiempo de respuesta.

Estoy completamente de acuerdo con Denis. Pero hay una forma de solucionarlo.

El problema de usar meta campos para valores que serán consultados es cuando los valores son arrays, etc. Como en este ejemplo:

array(
'key1' => 'val 1',
'key2' => 'val 2'
);

Esto se almacena en la base de datos como una cadena serializada, que se verá algo así:

{array["key1"]...{}...}

Entonces, cuando quieras consultar todos los posts con array['key2'] = 'val 2', WordPress tiene que recuperar cada entrada meta llamada 'array', deserializarla, evaluarla y pasar a la siguiente. Esto definitivamente ralentizará tu servidor si tu sitio tiene éxito y contiene muchos posts, páginas, custom posts, etc.

La solución depende del proyecto, y verás por qué. Si almacenas los datos como var = val, WordPress podrá buscarlos sin necesidad de que PHP desempaquete cada prueba. Para hacer esto en el escenario anterior, usarías algún tipo de namespacing y almacenarías las meta claves así:

_array_key1 = 'val 1';
_array_key2 = 'val 2';

Entonces, cuando WordPress busque la clave 2 con valor 'val 2', podrá recuperarla directamente. Sin embargo, esto depende del proyecto. Mi proyecto actual requiere almacenar unos 20 tipos diferentes de datos con cada custom post, por lo que el método anterior simplemente crearía una tabla enorme para buscar, considerando que esperamos tener cientos de miles de posts. En ese escenario, una tabla personalizada es la única solución.

Espero que esto le ayude a alguien

Para mi sitio de FarmVille :) Hice ambas cosas pero nunca lo terminé porque lo vendí:

1. Leí el XML de FarmVille y volqué los datos en una tabla personalizada
2. En WordPress tenía campos personalizados creados automáticamente para cada campo en esa tabla (y algunos extras)
3. Ahora la preocupación es qué pasa si un valor cambia tanto en la tabla como en el otro lado: el campo personalizado ya que necesitan estar continuamente sincronizados

Hice esto porque quería por un lado que los usuarios editaran el sitio WordPress introduciendo nuevos datos de FarmVille, por ejemplo "una vaca cuesta 10 monedas" PERO desde el lado de la integración: SI un cambio en el XML significaba que la vaca ahora cuesta "20 monedas" (a través del plugin de edición front-end), eso se daría como opción después: de modo que O el XML O el usuario tuviera razón (una especie de sistema wiki).

Así que aquí hay un ejemplo cuando se usan ambos.