Si quiero guardar la configuración de mi complemento, es bastante sencillo y sencillo.
Ahora me gustaría guardar un poco más en la base de datos.
Un nombre de archivo y otros 3 valores que solo se aplican a ese archivo. Y hay muchos archivos con esos valores. ¿Es posible guardar tipos de subarrays utilizando métodos de base de datos integrados? ¿Cómo puedo eliminarlos y ordenarlos, etc.?
Rara vez estoy en desacuerdo con usuarios expertos, pero en este caso no puedo evitarlo. En mi opinión, considerar incorrecto el uso de tablas de base de datos no centrales es simplemente incorrecto.
La elección de ir con las tablas centrales o agregar las suyas depende de varios factores.
El tiempo de ejecución de una consulta depende del tamaño de la tabla. Por lo tanto, si planea almacenar una gran cantidad de datos, inevitablemente será una solución más eficiente una tabla separada que se ocupe de este tipo de conjunto de datos específico.
Si almacena una gran cantidad de publicaciones regulares o CPT junto con estos conjuntos de datos específicos, wp_posts y wp_postmeta pueden crecer rápidamente.
Para mí, esta elección depende en última instancia de qué tan "posty" sean los datos. ¿Debería ser compatible con un autor, comentarios, revisiones, extractos o similares? Si es así, voy a ir con CPTs y / o funcionalidad principal. Si no, iré con tablas separadas por el uso y la eficiencia de los recursos.
Si la idea de Eugene fuera correcta, ninguno de los complementos bien escritos existentes agregaría sus propias tablas, lo que afortunadamente no es el caso.
$wpdb class . wp_options , y obligando al desarrollador del complemento a considerar cuidadosamente el tipo de los datos que se crean / almacenan, ¿es un CPT? ¿Es una taxonomía? es post meta? Sin embargo, para los casos de uso donde se necesita una tabla de base de datos separada, asegúrese de usar el método que WordPress proporciona para agregar su tabla personalizada a la base de datos de WordPress , especialmente para que pueda aprovechar la poderosa clase $wpdb . Tenga en cuenta la información / advertencias de esta lista de entradas del Codex:
Información de configuración : las opciones de usuario que se ingresan cuando el usuario configura su complemento por primera vez, y no tienden a crecer mucho más allá de eso (por ejemplo, en una etiqueta relacionada complemento, las opciones del usuario con respecto al formato de la nube de etiquetas en la barra lateral). La información de configuración generalmente se almacenará mediante el mecanismo de opciones de WordPress.
Datos : información que se agrega a medida que el usuario continúa usando su complemento, que generalmente es información expandida relacionada con publicaciones, categorías, cargas y otros componentes de WordPress (por ejemplo, en un complemento relacionado con estadísticas, las distintas vistas de página, las referencias y otras estadísticas asociadas con cada publicación en su sitio). Los datos se pueden almacenar en una tabla MySQL separada, que se tendrá que crear. Antes de saltar con una tabla completamente nueva, sin embargo, considera si almacenar los datos de tu complemento en WordPress 'Post Meta (a.k.a. Campos personalizados) funcionaría. Post Meta es el método preferido; utilícelo cuando sea posible / práctico.
Por lo tanto, podemos concluir lo siguiente:
Las tablas de base de datos no centrales son obligatorias si sus datos son más complejos que el modelo de publicación de WordPress, serán enormes y tendrán muchos detalles meta que se buscarán.
El formato de EAV que WordPress usa para su meta meta no se presta bien para la búsqueda de criterios múltiples.
Si divide su meta en muchas entradas, tendrá numerosas entradas por publicación en la tabla de meta de publicación, y la búsqueda de cualquier publicación a través de metas será mucho más lenta.
Si almacena todas las metas serializadas en una matriz y las tiene como una sola entrada en la meta posterior, esta vez se verá obligado a hacer solo búsquedas de texto dentro de esa meta, y no podrá usar operadores de comparación directamente en su consulta sql.
No es un gran problema si su complemento no va a tener miles de entradas y meta asociada.
Pero un problema importante si su complemento va a hacer algo grande.
Su situación, un nombre de archivo como entrada independiente y 3 entradas de metadatos adjuntas a esa entrada no parecen tan grandes. Puedes usar wordpress post table y meta table para ello.
PERO, si la gente va a buscar estas 3 metas mucho, ESPECIALMENTE en conjunto, entonces te recomiendo que configures tablas separadas.
Con ese formato, solo una tabla con una sola entrada, que también contiene todas las metas, estaría bien y haría consultas rápidas.
Por cierto, si usa tablas de WordPress y también usa el almacenamiento en caché de consultas, las búsquedas de los usuarios de sus datos se almacenarán en el caché con el tiempo e incurrirán en menos carga. Pero eso no sería tan prudente como hacer tablas separadas.
Puedes subir tus archivos a la biblioteca de medios. Cada elemento de la biblioteca de medios se almacena en la tabla wp_posts . Significa que cada archivo puede tener metadatos. Puede guardar toda la información que necesite para cada archivo en la tabla wp_postmeta usando API de metadatos .
¿Es una mala práctica crear una tabla propia para un complemento?
Sí, es una mala práctica crear una tabla propia, si puedes usar la funcionalidad principal en su lugar.
class TMM {
public static $options;
public static function register() {
self::$options = get_option(TMM_THEME_PREFIX . 'theme_options');
}
public static function get_option($option) {
return @self::$options[$option];
}
public static function update_option($option, $data) {
self::$options[$option] = $data;
update_option($prefix . 'theme_options', self::$options);
}
//ajax
public static function change_options() {
$action_type = $_REQUEST['type'];
$data = array();
parse_str($_REQUEST['values'], $data);
$data = self::db_quotes_shield($data);
if (!empty($data)) {
foreach ($data as $option => $newvalue) {
if (is_array($newvalue)) {
self::update_option($option, $newvalue);
} else {
$newvalue = stripcslashes($newvalue);
$newvalue = str_replace('\"', '"', $newvalue);
$newvalue = str_replace("\'", "'", $newvalue);
self::update_option($option, $newvalue);
}
}
}
_e('Options have been updated.', TMM_THEME_FOLDER_NAME);
exit;
}
public static function db_quotes_shield($data) {
if (is_array($data)) {
foreach ($data as $key => $value) {
if (is_array($value)) {
$data[$key] = self::db_quotes_shield($value);
} else {
$value = stripslashes($value);
$value = str_replace('\"', '"', $value);
$value = str_replace("\'", "'", $value);
$data[$key] = $value;
}
}
}
return $data;
}
}