Requêtes directes de base de données dans WordPress

Si vous revenez sur l’un des messages que j’ai écrits au cours des deux dernières années, par exemple, vous me trouverez probablement en train de préconiser l’utilisation des API disponibles sur les requêtes de base de données d’annuaire presque à chaque fois.

Et la vérité est que je penche toujours dans cette direction. Autrement dit, s’il existe une abstraction ou une API disponible pour faire quelque chose de spécifique, j’essaie de l’utiliser.

Mais dans quelques projets récents, j’ai travaillé avec des ensembles de données relativement volumineux (importants par rapport aux ensembles de données non professionnels). Et ce faisant, j’ai essayé de faire en sorte que les mises à jour des données soient aussi rapides que possible.

Dans des situations comme celle-ci, bien que les normes de codage WordPress ne l’ aiment pas, je trouve parfois que les requêtes directes dans la base de données sont la meilleure option pour le faire dans certaines conditions.

Utilisation de requêtes directes de base de données

Les requêtes directes de base de données font partie de ces choses qui ont une réputation un peu mitigée parmi les développeurs WordPress :

• ils sont découragés dans les normes de codage,
• WordPress offre un accès direct à la base de données via $wpdb,
• il y a des nuances dans les requêtes de base de données qui doivent être comprises.

Alors quand tu vois quelque chose comme ça :

<?php

private function set_all_scheduled_events_as_public() {

    global $wpdb;

    // @codingStandardsIgnoreStart
    $wpdb->query(
        $wpdb->prepare(
            "
            UPDATE $wpdb->posts
            SET post_status = '%s'
            WHERE post_type = '%s'
            AND post_status = '%s'
            ",
            'publish',
            'tribe_events',
            'future') );
    // @codingStandardsIgnoreEnd
}

Comment savoir si c’est un bon coup ou pas? Et mieux encore, comment savoir si vous devez utiliser des requêtes de base de données d’annuaire dans votre propre code ?

Il y a quelques questions que je me pose normalement lorsque je les traite, toutes partagées ci-dessous.

1 Y a-t-il des index sur les colonnes ?

Avant d’utiliser des requêtes directes de base de données dans WordPress, il faut vérifier si les colonnes que j’interroge ont des index sur lesdites colonnes.

Et la raison est celle-ci :

Les index sont utilisés pour localiser rapidement les données sans avoir à rechercher chaque ligne dans une table de base de données à chaque accès à une table de base de données.

L’essentiel est que la vitesse à laquelle vous pouvez interroger et mettre à jour les colonnes est plus rapide s’il existe des index sur les colonnes.

Les requêtes directes de base de données dépendent de la structure de la base de données.

À cette fin, ce n’est pas quelque chose que nous devrions faire tout le temps. Mais il y a des moments où c’est approprié (comme lorsque vous mettez à jour un ensemble de méta-valeurs) et quand ce n’est pas le cas.

2 Paramétrez vos requêtes

Lorsque vous utilisez des requêtes directes de base de données, il est extrêmement important de paramétrer vos requêtes pour des raisons de sécurité. Vous pouvez tout lire à ce sujet dans le Codex, et ce n’est pas quelque chose à ignorer.

Directement de la documentation :

Pour un aperçu plus complet de l’échappement SQL dans WordPress, consultez Validation des données de la base de données. C’est une lecture incontournable pour tous les contributeurs de code WordPress et les auteurs de plugins.

Autrement dit, si vous prenez des entrées d’utilisateurs, vous devez vous assurer qu’elles sont nettoyées, propres et prêtes à être insérées dans la base de données. Mais, pour ce que ça vaut, je n’autorise presque jamais la saisie de l’utilisateur à avoir un impact sur les requêtes directes de la base de données.

Au lieu de cela, ils sont normalement basés sur des données que j’ai dans le code et que je souhaite mettre à jour ou modifier lorsqu’ils sont en toute sécurité dans le domaine de contrôle de la base de code.

3 Testez-les et testez-les à nouveau

Et enfin, avant d’implémenter des requêtes directes, je recommande :

1. Démarrage de votre front-end SQL et exécution des requêtes,
2. Notez toutes les erreurs qu’ils peuvent lancer,
3. Corrigez-les et réessayez.

Ensuite, une fois que vous avez un test de requête fonctionnel pour les cas extrêmes pour vous assurer que quelque chose ne va pas être mutilé. Cela est particulièrement vrai si vous allez utiliser des clauses LIKE dans vos requêtes (ce qui est probablement un article en soi).

Me manque-t-il une API ?

Avec la taille de l’API de WordPress, il y a toujours une chance que je manque quelque chose, que je néglige quelque chose ou que je ne sois tout simplement pas intelligent avec les API existantes.

Et si tel est le cas, je me ferai un plaisir de corriger les informations ci-dessus (n’hésitez donc pas à laisser un commentaire).

Mais en attendant, si vous travaillez avec une donnée relativement définie, vous êtes sûr qu’il y a des index sur les colonnes, vous savez comment paramétrer les requêtes, et vous avez testé les données, puis peut-être faire avec direct les requêtes de base de données sont la voie à suivre.

Et si tel est le cas, il existe plusieurs façons d’ignorer les normes de codage sans que PHP CodeSniffer ne vous crie dessus. 🙂