web-dev-qa-db-fra.com

Est-ce une mauvaise pratique de créer sa propre table pour un plugin?

Si je veux sauvegarder les paramètres de mon plugin, c'est assez simple et rapide.

Maintenant, j'aimerais enregistrer un peu plus dans la base de données.

Un nom de fichier et 3 autres valeurs qui ne s'appliquent qu'à ce fichier. Et il y a beaucoup de fichiers avec ces valeurs. Est-il possible de sauvegarder des types de sous-réseaux en utilisant des méthodes de base de données intégrées? Comment puis-je les supprimer et les trier, etc.?

pluginsdatabase
10
Badr Hari

Je suis rarement en désaccord avec des utilisateurs autrement avertis, mais dans ce cas, je ne peux pas m'en empêcher. À mon avis, appeler l'utilisation de tables de base de données non principales une mauvaise pratique en soi est tout simplement une erreur.

Le choix d’aller avec les tables principales ou d’ajouter les vôtres dépend de plusieurs facteurs.

Le temps d'exécution d'une requête dépend de la taille de la table. Par conséquent, si vous prévoyez de stocker des quantités importantes de données, une solution distincte, qui ne concerne que ce type de jeu de données spécifique, sera inévitablement la solution la plus efficace.

Si vous stockez un grand nombre de publications régulières ou de fichiers CPT à côté de ces ensembles de données spécifiques, wp_posts ainsi que wp_postmeta peuvent croître rapidement.

Pour moi, ce choix dépend en fin de compte de la "posty" des données. Devrait-il soutenir un auteur, des commentaires, des révisions, des extraits ou similaires? Si tel est le cas, je choisirai les CPT et/ou les fonctionnalités principales. Si ce n'est pas le cas, je choisirai des tableaux distincts pour des raisons d'utilisation et d'efficacité des ressources.

Si la notion d'Eugene était correcte, aucun des plugins existants bien écrit n'ajouterait ses propres tables, ce qui n'est heureusement pas le cas.

12
Johannes Pille

L'utilisation de WP tables de base de données DB est la meilleure pratique

  1. L'utilisation de tables de base de données rend vos données plus portables , et plus faciles à sauvegarder, car elles seront gérées par l'exportateur/importateur principal, ainsi que par la myriade de plugins de sauvegarde.
  2. L’utilisation de tables de base de données simplifie la manipulation de vos données , car vous aurez un accès plus intuitif aux diverses fonctions de base de WordPress relatives à la recherche, l’ajout, la modification, la suppression et la désinfection des données de la base de données, notamment via la très puissant $wpdb classe .
  3. L'utilisation de tables de base de données de base encourage/facilite les meilleures pratiques en matière de classification et de stockage de données , telles que le stockage des options de plug-in sous forme de tableau sur une seule ligne dans wp_options et en obligeant le développeur de plug-in à bien prendre en compte le type de données en cours. créé/stocké - s'agit-il d'un CPT? est-ce une taxonomie? est-ce post meta?
  4. Votre plugin est moins susceptible de laisser derrière lui cruellement lorsque vous utilisez des tables de base de données DB.

WordPress fournit aux plugins un moyen d'ajouter des tables à sa base de données

Toutefois, dans les cas où une table de base de données distincte est nécessaire, veillez à utiliser la méthode fournie par WordPress pour ajouter votre table personnalisée à la base de données WordPress , en particulier pour pouvoir tirer parti de la puissante classe $wpdb. Notez les informations/mises en garde répertoriées dans cette entrée du Codex:

  • Informations de configuration - les choix de l'utilisateur qui sont entrés lors de la première configuration de votre plugin et ne poussent pas beaucoup plus loin (par exemple, dans un plugin associé à une balise, les choix de l'utilisateur concernant la format du nuage de tags dans la barre latérale). Les informations de configuration seront généralement stockées à l'aide du mécanisme d'options WordPress.

  • Données - informations ajoutées au fur et à mesure que l'utilisateur continue à utiliser votre plug-in, qui sont généralement des informations développées relatives aux publications, catégories, téléchargements et autres composants WordPress (par exemple, dans un plug-in lié aux statistiques, les différentes pages vues, les référents et autres statistiques associées à chaque publication sur votre site). Les données peuvent être stockées dans une table MySQL distincte, qui devra être créée. Avant de sauter avec une nouvelle table, cependant, considérez si le stockage des données de votre plugin dans Post Meta de WordPress (a.k.a. Custom Fields) fonctionnerait. Post Meta est la méthode préférée. utilisez-le quand c'est possible/pratique.

Ainsi, nous pouvons conclure ce qui suit:

  1. Stocker des données (définies par l'utilisateur ou générées par l'utilisateur) dans les tables WP principales est meilleure pratique
  2. Il existe des cas d'utilisation valides pour la création de tables de base de données personnalisées. par conséquent, la création de tables de base de données personnalisées ne peut pas être considérée comme une inhérente mauvaise pratique
  3. Lors de la création de tables de base de données personnalisées, WordPress fournit une implémentation recommandée.
5
Chip Bennett

Les tables de base de données non essentielles sont indispensables si vos données sont plus complexes que le post-modèle WordPress, elles seront énormes et comporteront de nombreuses méta-détails qui feront l'objet d'une recherche.

Le format EAV que WordPress utilise pour sa publication meta ne se prête pas bien à la recherche multicritère.

Si vous divisez votre méta en plusieurs entrées, vous aurez plusieurs entrées par publication dans la table des méta-publications, et la recherche de toute publication via méta sera beaucoup plus lente.

Si vous stockez toutes les méta sérialisées dans un tableau et que vous ne l'avez qu'une seule entrée dans post méta, cette fois, vous serez obligé de faire uniquement des recherches de texte à l'intérieur de cette méta et vous ne pourrez pas utiliser d'opérateurs de comparaison directement dans votre requête SQL.

Pas un gros problème si votre plugin ne va pas avoir des milliers d'entrées et méta associé.

Mais un problème majeur si votre plugin va faire quelque chose de grand.

Votre situation, un nom de fichier en tant qu'entrée indépendante et 3 entrées de métadonnées attachées à cette entrée ne semble pas si grosse. Vous pouvez utiliser wordpress post table et meta table pour cela.

MAIS, si les gens recherchent beaucoup ces 3 méta, en particulier en conjonction, alors je vous recommande de configurer des tables séparées.

Avec ce format, une seule table avec une seule entrée, contenant également tous les métas serait acceptable, et interrogerait rapidement.

Incidemment, si vous utilisez des tables WordPress et que vous utilisez également la mise en cache des requêtes, l’utilisateur cherchant vos données sera mis en cache avec le temps et subira moins de charge. Mais cela ne serait pas aussi prudent que de faire des tables séparées.

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

}
  • Le nom de la classe est original, renommez-le comme vous le souhaitez.
  • Dans les fonctions php, ajoutez: add_action ('init', array ('TMM', 'register'), 1);
  • Et ajoutez pour ajax: add_action ('wp_ajax_change_options', array ('TMM', 'change_options'));
  • Pour obtenir l’option où vous en avez besoin, utilisez ceci (par exemple): $ logo_img = TMM :: get_option ('logo_img');
  • Utilisez-le pour enregistrer vos options par les méthodes wordpress natives
0
realmag777

Vous pouvez télécharger vos fichiers dans la médiathèque. Chaque élément de la bibliothèque multimédia est stocké dans la table wp_posts. Cela signifie que chaque fichier peut avoir des métadonnées. Vous pouvez enregistrer autant d'informations que nécessaire dans chaque fichier de la table wp_postmeta à l'aide de Metadata API .

Est-ce une mauvaise pratique de créer sa propre table pour un plugin?

Oui, il est déconseillé de créer sa propre table si vous pouvez utiliser les fonctionnalités principales.

0
Eugene Manuilov