Étant donné que db_select est beaucoup plus lent que db_query, pourquoi voudrais-je l'utiliser?


Réponses:


88

Il y a 5 raisons d'utiliser SelectQuery

  • Vous construisez des requêtes dynamiques avec un nombre variable de conditions, jointures, champs, etc. Voir field_read_fields () pour un exemple.

  • Vous voulez utiliser ce qu'on appelle des Extender . Des exemples d'extension sont PagerDefault (remplace pager_query () ) et TableSort (remplace tablesort_sql () ). Ceux-ci permettent d'ajouter des fonctionnalités supplémentaires à SelectQuery. Voir aussi Comment créer des tables triables avec un pager avec les données d'une table personnalisée? . Un exemple: node_page_default () .

  • Vous souhaitez autoriser d'autres modules à modifier vos requêtes. Vous pouvez ensuite ajouter ce que vous appelez des balises et SelectQuery appellera automatiquement un autre crochet correspondant pour cette balise. Je compte beaucoup sur cela avec mon module Privatemsg (nous l'avions déjà fait dans D6 avec un constructeur de requêtes personnalisé).

  • Si vous souhaitez / devez utiliser le système node_access pour afficher uniquement les nœuds que l'utilisateur est autorisé à voir. Ajoutez simplement la balise 'node_access' à votre requête $. Ceci remplace db_rewrite_sql ().

  • SelectQuery présente quelques fonctionnalités qui permettent de rendre votre code identique sur toutes les bases de données prises en charge. Par exemple, il y a SelectQuery :: orderRandom () . Et si vous avez une condition LIKE, -> condition ('champ', $ valeur, 'LIKE') s'assurera qu'il s'agit toujours d'une comparaison insensible à la casse. En D6, vous deviez utiliser LOWER () pour ce qui était beaucoup plus lent. Mais autant que je sache, il n'y a pas plus que ces deux-là pour le moment.

Si aucune de ces raisons ne s'applique à un cas spécifique, utilisez db_query ().


1
Ajout d'un cinquième point, les fonctionnalités de portabilité de la base de données telles que orderRandom () et LIKE, insensible à la casse.
Berdir

6
En sixième lieu, j'ajouterais une compatibilité croisée avec les bases de données. La syntaxe des requêtes Oracle, par exemple, diffère à certains égards de MySQL, de Postgres, etc. est déversé directement dans db_query ().
BrianV

9

La documentation surdb_query() dit:

Utilisez cette fonction pour les requêtes SELECT s'il ne s'agit que d'une simple chaîne de requête. Si l'appelant ou d'autres modules doivent modifier la requête, utilisez plutôt db_select ().


Merci, mais c'est assez peu spécifique. Cela laisse la définition de 'chaîne de requête simple' assez ouverte à interprétation. Si je sélectionne 4 tables avec 6 jointures, s'agit-il encore d'une simple requête ou faut-il plutôt le faire avec db_select ()?
Chris Cohen

3
Il ne s'agit pas d'une "requête simple", mais d'une " chaîne de requête simple " et simple signifie en réalité codé en dur et non dynamique. Voir ma réponse pour plus de détails :)
Berdir

9

J'utilise toujours db_select car je préfère la lisibilité, la maintenabilité et la compatibilité entre bases de données plutôt que de gagner en performances. De plus, je pense que les chiffres donnés dans le numéro mentionné donnent une image fausse de la performance globale. Nous parlons d'une différence de 300 microsecondes sur une requête qui, lors du renvoi de plusieurs colonnes, est souvent exécutée dans la plage de plusieurs millisecondes. Et je ne serais pas surpris s'il y a une surcharge unique (chargement de classe) et donc que les différences pour une demande complète (page) sont bien moindres.


La différence de performance n’est pas si simple; voir Comparaison des performances de db_query et db_select . Je recommande généralement db_query à db_select, sauf si vous avez besoin de l'une des fonctionnalités spéciales mentionnées dans la réponse de Berdir.
geerlingguy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.