¿Es una mala práctica crear una tabla propia para un complemento?

Si quiero guardar la configuración de mi complemento, es bastante fácil y directo.

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 submatrices utilizando métodos de base de datos integrados? ¿Cómo puedo eliminarlos y ordenarlos, etc.?

Raramente estoy en desacuerdo con usuarios conocedores, pero en este caso no puedo evitarlo. En mi opinión, llamar al uso de tablas de bases de datos no centrales una mala práctica per se es simplemente incorrecto.

La elección de si elegir tablas centrales o agregar las propias 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 cantidades significativas de datos, una tabla separada que atienda solo a este tipo de conjunto de datos específico será inevitablemente la solución más eficiente.

Si almacena muchas publicaciones regulares o CPT junto con estos conjuntos de datos específicos, wp_poststambién wp_postmetapuede crecer rápidamente.

Para mí, esta elección depende en última instancia de cuán "elegantes" sean los datos. ¿Debería ser compatible con un autor, comentarios, revisiones, extractos o similares? Si es así, iré con CPT y / o funcionalidad principal. Si no, iré con tablas separadas por el uso y la eficiencia de los recursos.

Si la noción de Eugene fuera correcta, ninguno de los complementos bien escritos existentes agregaría sus propias tablas, lo que afortunadamente no es el caso.

El uso de tablas WP core DB es la mejor práctica

1. El uso de tablas de base de datos principales hace que sus datos sean más portátiles y más fáciles de respaldar, ya que serán manejados por el exportador / importador principal, así como por la miríada de complementos de respaldo
2. El uso de tablas de base de datos hace que sus datos sean más fáciles y seguros de manipular , ya que tendrá un acceso más intuitivo a las diversas funciones básicas de WordPress relacionadas con la consulta, adición, modificación, eliminación y desinfección de datos de base de datos, particularmente a través de la $wpdbclase muy poderosa .
3. El uso de tablas de base de datos alienta / facilita las mejores prácticas para la clasificación y el almacenamiento de datos , como el almacenamiento de las opciones del complemento como una matriz en una sola fila wp_optionsy al obligar al desarrollador del complemento a considerar cuidadosamente el tipo de datos que se crean / almacenan, CPT? ¿Es una taxonomía? ¿Es post meta?
4. Es menos probable que su complemento deje atrás cuando utiliza tablas de base de datos centrales.

WordPress proporciona un medio para que los complementos agreguen tablas a su base de datos

Sin embargo, para aquellos casos de uso en los que se necesita una tabla de base de datos separada, asegúrese de usar el método que proporciona WordPress para agregar su tabla personalizada a la base de datos de WordPress , especialmente para que pueda aprovechar la $wpdbclase poderosa . Tenga en cuenta la información / advertencias que enumera esta entrada 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 un complemento relacionado con etiquetas, 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á utilizando 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 ampliada relacionada con publicaciones, categorías, cargas y otros componentes de WordPress (por ejemplo, en un complemento relacionado con estadísticas, las diversas vistas de página, referencias , y otras estadísticas asociadas con cada publicación en su sitio). Los datos se pueden almacenar en una tabla MySQL separada, que deberá crearse. Sin embargo, antes de saltar con una tabla completamente nueva, considere si almacenar los datos de su complemento en WordPress 'Post Meta (también conocido como Campos personalizados) funcionaría. Post Meta es el método preferido; Úselo cuando sea posible / práctico.

Por lo tanto, podemos concluir lo siguiente:

1. Almacenar datos (configuración o generados por el usuario) en tablas centrales de WP es la mejor práctica
2. Existen casos de uso válidos para crear tablas de base de datos personalizadas; por lo tanto, crear tablas de base de datos personalizadas no puede considerarse una mala práctica inherente
3. Al crear tablas de base de datos personalizadas, WordPress proporciona una implementación de mejores prácticas

Las tablas de bases de datos no básicas son imprescindibles si sus datos son más complejos que el modelo de publicación de WordPress, va a ser enorme y tiene muchos metadatos que se buscarán.

El formato EAV que WordPress usa para su meta meta no se presta bien a 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 meta, 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 la tiene como solo una entrada en el meta meta, esta vez se verá obligado a hacer solo búsquedas de texto dentro de ese 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 asociados.

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 parece tan grande. Puede usar la tabla de publicaciones de WordPress y la tabla meta para ello.

PERO, si la gente va a buscar mucho estas 3 metas, ESPECIALMENTE en conjunto, entonces recomendaría que establezca tablas separadas.

Con ese formato, solo una tabla con una sola entrada, que también contiene todas las metas, estaría bien y consultaría a la velocidad del rayo.

Por cierto, si usa tablas de WordPress y también está usando el almacenamiento en caché de consultas, el usuario busca sus datos que se almacenarán en caché con el tiempo e incurrirán en menos carga. Pero eso no sería tan prudente como hacer tablas separadas.

Puede cargar sus archivos en la biblioteca de medios. Cada elemento en la biblioteca de medios se almacena en la wp_poststabla. Significa que cada archivo puede tener metadatos. Puede guardar tanta información como necesite por cada archivo en la wp_postmetatabla utilizando la 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 en su lugar puede utilizar la funcionalidad principal.

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;
    }

}

• El nombre de la clase es original, cámbiele el nombre como desee.
• En las funciones php add: add_action ('init', array ('TMM', 'register'), 1);
• Y agregue para ajax: add_action ('wp_ajax_change_options', array ('TMM', 'change_options'));
• Para obtener la opción donde necesita usar esto (por ejemplo): $ logo_img = TMM :: get_option ('logo_img');
• Úselo para guardar sus opciones mediante métodos nativos de WordPress