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

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

J'aimerais maintenant enregistrer un peu plus dans la base de données.

Un nom de fichier et 3 autres valeurs qui s'appliquent uniquement à ce fichier. Et il existe de nombreux fichiers avec ces valeurs. Est-il possible d'enregistrer 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.?

Je suis rarement en désaccord avec des utilisateurs par ailleurs bien informés, mais dans ce cas, je ne peux pas m'en empêcher. À mon avis, qualifier de mauvaise pratique l'utilisation de tables de base de données non essentielles est tout simplement faux.

Le choix entre utiliser des tables de base ou 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 table distincte réservée à ce seul type d'ensemble 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 CPT à côté de ces ensembles de données spécifiques, wp_postsainsi que wp_postmetapeut croître rapidement.

Pour moi, ce choix dépend en fin de compte de la "position" des données. Doit-il prendre en charge un auteur, des commentaires, des révisions, des extraits ou similaires? Si oui, j'irai avec des CPT et / ou des fonctionnalités de base. Sinon, je vais utiliser des tableaux séparés pour des raisons d'utilisation des ressources et d'efficacité.

Si la notion d'Eugène était correcte, aucun des plugins bien écrits existants n'ajouterait leurs propres tables, ce qui n'est heureusement pas le cas.

L'utilisation des tables de base de données WP est recommandée

1. L'utilisation des 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 des tables de base de données DB rend vos données plus faciles et plus sûres à manipuler , car vous aurez un accès plus intuitif aux différentes fonctions principales de WordPress liées à l'interrogation, l'ajout, la modification, la suppression et la désinfection des données de la base de données, en particulier grâce à la $wpdbclasse très puissante .
3. L'utilisation des tables de base de données de base encourage / facilite les meilleures pratiques de classification et de stockage des données , telles que le stockage des options de plug-in sous forme de tableau sur une seule ligne wp_options, et en forçant le développeur du plug- in à examiner attentivement le type de données créées / stockées - est-ce un CPT? est-ce une taxonomie? est-ce post meta?
4. Votre plugin est moins susceptible de laisser des traces lors de l'utilisation des tables de base de données.

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

Cependant, pour les cas d'utilisation 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 que vous puissiez profiter de la $wpdbclasse puissante . Notez les informations / mises en garde de cette liste d'entrées Codex:

• Informations de configuration - choix de l'utilisateur qui sont entrés lors de la première configuration de votre plug-in par l'utilisateur et qui n'ont pas tendance à s'étendre bien au-delà (par exemple, dans un plug-in lié aux balises, les choix de l'utilisateur concernant le format du nuage de balises 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 d'utiliser votre plug-in, qui est généralement des informations étendues liées 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 d'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 vous lancer avec une toute nouvelle table, cependant, demandez-vous si le stockage des données de votre plugin dans Post Meta de WordPress (alias Champs personnalisés) fonctionnerait. Post Meta est la méthode préférée; utilisez-le lorsque cela est possible / pratique.

Ainsi, nous pouvons conclure ce qui suit:

1. Le stockage des données (configurées ou générées par l'utilisateur) dans les tables WP de base est la meilleure pratique
2. Il existe des cas d'utilisation valides pour créer des 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 mauvaise pratique inhérente
3. Lors de la création de tables de base de données personnalisées, WordPress fournit une implémentation des meilleures pratiques

Les tables de base de données non essentielles sont indispensables si vos données sont plus complexes que le modèle de publication WordPress, elles vont être énormes et elles contiennent beaucoup de méta-détails qui seront recherchés.

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 de nombreuses entrées par publication dans la table des méta-publications, et la recherche de n'importe quelle publication via les métas sera beaucoup plus lente.

Si vous stockez toutes les métas sérialisées dans un tableau et que vous ne les avez qu'une seule entrée dans la méta post, 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 des méta associées.

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

Votre situation, un nom de fichier comme entrée indépendante et 3 entrées de métadonnées attachées à cette entrée ne semblent pas si grandes. Vous pouvez utiliser la table de publication wordpress et la méta-table pour cela.

MAIS, si les gens vont souvent chercher ces 3 métas, PARTICULIÈREMENT en conjonction, alors je vous recommande de mettre en place des tables séparées.

Avec ce format, une seule table avec une seule entrée, qui contient également toutes les métas, serait correcte et interrogerait rapidement.

Par ailleurs, si vous utilisez des tableaux WordPress et que vous utilisez également la mise en cache des requêtes, l'utilisateur recherche vos données serait mis en cache au fil du temps et encourra moins de charge. Mais ce ne serait pas aussi prudent que de faire des tableaux séparés.

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

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

Oui, c'est une mauvaise pratique de créer sa propre table, si vous pouvez utiliser à la place les fonctionnalités de base.

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 add: 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 là où vous en avez besoin, utilisez ceci (par exemple): $ logo_img = TMM :: get_option ('logo_img');
• Utilisez-le pour enregistrer vos options par des méthodes WordPress natives