¿Todas las opciones de WordPress como opción única (matriz multidimensional serializada) o opciones múltiples?

5 minutos de lectura

avatar de usuario de user3237169
usuario3237169

Conozco WordPress, pero en este momento estoy desarrollando un complemento de WordPress bastante grande y avanzado.

Por esta razón, he pensado mucho en mi estructura de datos.

Cuando era principiante, siempre solía guardarlo así (get_option(prefix_option_name)). Luego comencé a usar arreglos multidimensionales, registrando 1 para cada configuración_sección y ahora normalmente guardo todas las opciones de complemento en 1 gran arreglo multidimensional como este: plugin_options[section][option][evt.more subs here][etc]

Esto funciona bien, y me gusta el hecho de que puedo extraer todas las opciones una vez en el gancho de inicio ($plugin_options = get_option(‘plugin_options), para poder trabajar con las $opciones “localmente” en el complemento , SIN EMABARGO…

Teniendo en cuenta que WordPress ya está utilizando transitorios para almacenar en caché (WP Cache API) la llamada get_option, ¿Cuál es mejor para el rendimiento? Aunque mi complemento tiene muchas opciones, supongo que nunca podría alcanzar el límite del tipo de texto largo (datos de 4 gb o algo así), incluso si lo empaqueté todo en una sola matriz multidimensional serializable. Pero quiero hacer lo mejor desde el punto de vista del rendimiento, así que, en resumen, esta es mi pregunta nuevamente:

¿Qué es mejor (para un complemento de wordpress bastante grande y complejo)?

  1. Guardar todas las opciones de complementos como una sola opción (matriz multidimensional serializada), como, por ejemplo. nombre=”opciones_de_complemento[section][option]”
  2. Dividir cada pestaña de opciones y página de opciones en su propia entrada de opciones como, por ejemplo: sección[option][etc]
  3. simplemente anteponga todas las opciones de su complemento y colóquelas como una entrada de base de datos separada como, por ejemplo. nombre_complemento_opción_1, nombre_complemento_opción_2

Me gusta el enfoque de “opción de complemento único”, pero en este momento estoy confundido en cuanto a si obtener o actualizar 1 gran matriz de la base de datos es realmente la mejor manera de hacerlo, si la matriz se vuelve REALMENTE grande, como en un muy complemento grande y avanzado.

El problema con 3, tal como lo veo, es que con 1, solo necesitaría buscar todas las opciones en una llamada a db, mientras que en 3 (donde guarda cada opción como una entrada de db para sí misma), tendría que consultar el db para cada opción específica e individual.

Pero cuál es mejor 1 llamada para todas las opciones, 1 para cada sección o 1 para cada opción individual (supongo que mi pregunta podría reducirse a esto al final: D). ¿Puede la matriz multidimensional serializable de opción de complemento de “opción única” crecer demasiado de manera realista? ¿Debe dividirse?

Esperamos escuchar sus opiniones sobre esto. Salud. 🙂

Avatar de usuario de Ian Dunn
Ian Dunn

Tiendo a preferir opciones separadas para datos no relacionados. En la mayoría de los casos, no importa el rendimiento, pero existen beneficios significativos en comparación con la combinación de ambos.

Actuación

Si la opción es autocargado – que son por defecto – entonces usar opciones separadas no dará como resultado ninguna consulta adicional a la base de datos.

Si usa Memcache, los objetos están limitados de manera predeterminada a 1 mb, y si su opción crece más allá de eso, omitirá el almacenamiento en caché y accederá a la base de datos cada vez.

Otras Consideraciones

Creo que Core se ha diseñado con la suposición de que las opciones estarán separadas, por lo que si las combina, tendrá que hacer un trabajo adicional para utilizar algunas de las cosas útiles que Core le ofrece de forma gratuita.

Por ejemplo, todas estas prácticas comunes son fáciles de realizar con opciones individuales, pero requieren una lógica adicional para reducir la opción combinada a la entrada de destino:

También puede ser un problema de “todos los huevos en una canasta”; si un error o algún otro factor causa la pérdida de datos inesperada, el usuario puede perder todo, en lugar de solo un dato. Eso es raro en la práctica, pero lo he visto suceder, con efectos muy dañinos. La gente debería tener copias de seguridad, pero muchas no las tienen, y también he visto que las copias de seguridad fallan en la práctica.

Avatar de usuario de Benjamin Intal
Benjamín Intal

Personalmente, suelo optar por la opción única.

Si está utilizando varias opciones en una sola carga de página, cada una de ellas sería una llamada a db (a menos que se carguen automáticamente). Si está utilizando todas o la mayoría de sus opciones en una página de todos modos, entonces estaría guardando una llamada db para cada opción que está utilizando si las pone todas en una sola opción. Los ahorros aquí pueden acumularse rápidamente.

Sin embargo, esto todavía depende de la cantidad de datos que esté poniendo en su opción única. Si es bastante grande, deserializar o serializar sus datos podría tener un impacto en el rendimiento de su servidor. (ver: serializar una gran matriz en PHP?). Tendrá que hacer algún tipo de punto de referencia para medir cuál es más rápido si está manejando muchos datos.

FWIW, WordPress ya carga automáticamente y almacena en caché todas las opciones en cada carga de página (a menos que se guarde una opción para no hacerlo), por lo que realmente no importa.

¿Ha sido útil esta solución?