Persistencia avanzada con wpdb: tablas propias y migraciones sin perder datos
Aprendes cuándo salir de `options/postmeta`, cómo crear tablas propias con `dbDelta`, versionar esquema y ejecutar migraciones idempotentes con consultas seguras.
No todo cabe bien en `wp_options` o `postmeta`. Cuando necesitas consultas específicas, volumen alto o relaciones claras, una tabla propia suele ser la mejor decisión.
En esta lección diseñarás persistencia para eventos de avisos contextuales con `wpdb` y migraciones de esquema controladas.
El foco es evitar dos problemas clásicos: consultas inseguras y cambios de esquema que rompen instalaciones existentes.
Al terminar tendrás una base para evolucionar estructura de datos sin perder información de clientes.
- La elección de almacenamiento impacta rendimiento, mantenibilidad y coste de evolución.
- Si guardas pocos valores globales, `options` es perfecto. Si el dato cuelga de un post, `postmeta` puede ser suficiente.
- Pero si necesitas filtrar por fecha, tipo de evento o estado con volumen alto, una tabla propia evita consultas lentas y estructuras forzadas.
- Caso real: guardar logs de avisos en `options` generó un blob enorme difícil de consultar; pasar a tabla propia redujo tiempos y simplificó reporting.
- Datos globales simples: `options`.
Cuándo usar tabla propia en lugar de options o meta
La elección de almacenamiento impacta rendimiento, mantenibilidad y coste de evolución.
Si guardas pocos valores globales, `options` es perfecto. Si el dato cuelga de un post, `postmeta` puede ser suficiente.
Pero si necesitas filtrar por fecha, tipo de evento o estado con volumen alto, una tabla propia evita consultas lentas y estructuras forzadas.
Caso real: guardar logs de avisos en `options` generó un blob enorme difícil de consultar; pasar a tabla propia redujo tiempos y simplificó reporting.
- Datos globales simples: `options`.
- Datos por post/usuario: metadatos.
- Datos relacionales y voluminosos: tabla propia.
Crear y versionar esquema con dbDelta
Tu esquema debe poder evolucionar sin romper instalaciones ya activas.
En activación crea tabla inicial con `dbDelta` y guarda versión de esquema (`wpac_db_version`) en opciones.
En cada carga de plugin (o hook controlado) compara versión actual vs esperada y ejecuta migraciones pendientes.
Importante: las migraciones deben ser idempotentes; si se ejecutan dos veces, no deben duplicar ni corromper datos.
Consultas seguras: `prepare`, formato y límites
Nunca construyas SQL con concatenación de entradas de usuario.
Usa `$wpdb->prepare` en consultas con parámetros dinámicos y tipos correctos (`%d`, `%s`, `%f`).
Para inserciones sencillas, `$wpdb->insert` con formato explícito reduce errores y mejora legibilidad.
En lecturas de listas, añade límites y orden explícito para evitar consultas costosas inesperadas.
Caso real: añadir columna sin romper instalaciones antiguas
Una migración bien hecha respeta datos existentes y evita downtime.
Supón que en v1 guardabas solo `event_type` y `payload`, pero en v1.1 necesitas `source` para diferenciar admin/frontend.
En vez de forzar reset de tabla, ejecutas `ALTER TABLE` controlado durante migración y actualizas versión de esquema.
Después, tu código debe tolerar temporalmente instalaciones en versión anterior hasta completar migración.