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

10

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.?

    
pregunta Badr Hari 01.06.2012 - 12:50

5 respuestas

12

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.

    
respondido por el Johannes Pille 01.06.2012 - 13:30
5

Usar las tablas de base de datos de WP core es la mejor práctica

  1. El uso de las tablas de base de datos central hace que sus datos sean más portátiles y más fáciles de realizar copias de seguridad, ya que serán manejados por el exportador / importador central, así como por los innumerables complementos de copia de seguridad
  2. El uso de tablas de base de datos DB 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 saneamiento de los datos de la base de datos, particularmente a través de el muy poderoso $wpdb class .
  3. El uso de tablas de bases de datos centrales fomenta / facilita las mejores prácticas para la clasificación y el almacenamiento de datos , como almacenar las opciones del complemento como una matriz en una sola fila en 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?
  4. Es menos probable que su complemento deje atrás el cruft cuando use las tablas de base de datos centrales.

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

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:

  1. El almacenamiento de datos (configuración, o generado por el usuario) en las tablas principales de WP es la mejor práctica
  2. Hay casos de uso válidos para crear tablas de base de datos personalizadas; por lo tanto, la creación de tablas DB personalizadas no puede considerarse como una inherente mala práctica
  3. Al crear tablas de base de datos personalizadas, WordPress proporciona una implementación de las mejores prácticas
respondido por el Chip Bennett 01.06.2012 - 14:12
1

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.

    
respondido por el unity100 22.01.2016 - 00:43
0

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.

    
respondido por el Eugene Manuilov 01.06.2012 - 13:02
0
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, renómbrelo 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
respondido por el realmag777 07.06.2013 - 17:12

Lea otras preguntas en las etiquetas