Votre exemple de code est si simple qu'il y aura peu de différence, mais dans ce cas, la version statique s'exécutera probablement mieux.
La principale raison d'utiliser SQL dynamique pour les performances est lorsque l'instruction SQL peut varier de manière significative - c'est-à-dire que vous pourriez être en mesure d'ajouter du code supplémentaire à la clause WHERE lors de l'exécution en fonction de l'état du système (limité par une sous-requête sur l'adresse, si l'adresse est saisie, etc.).
Une autre raison est que l'utilisation de variables Bind comme paramètres peut parfois être contre-productive.
Par exemple, si vous avez quelque chose comme un champ d'état, où les données ne sont pas réparties uniformément (mais sont indexées).
Considérez les 3 déclarations suivantes, lorsque 95 % des données sont "traitées"
SELECT col FROM table
WHERE status = 'U'-- unprocessed
AND company = :company
SELECT col FROM table
WHERE status = 'P' -- processed
AND company = :company
SELECT col FROM table
WHERE status = :status
AND company = :company
Dans la version finale, Oracle choisira un plan d'exécution générique. Dans la première version, il peut décider que le meilleur plan est de commencer par l'index sur le statut (sachant que les entrées non traitées ne représentent qu'une très petite partie du total).
Vous pouvez implémenter cela via différentes instructions statiques, mais lorsque vous avez des instructions plus complexes qui ne changent que de quelques caractères, le SQL dynamique peut être une meilleure option.
Inconvénients
Chaque répétition de la même instruction SQL dynamique entraîne une analyse logicielle, ce qui représente une petite surcharge par rapport à une instruction statique, mais toujours une surcharge.
Chaque NOUVELLE instruction sql (dynamique ou statique) entraîne également un verrou sur la SGA (mémoire partagée) et peut entraîner la suppression des "anciennes" instructions.
Une conception de système mauvaise, mais courante, consiste pour quelqu'un à utiliser SQL dynamique pour générer des sélections simples qui ne varient que par clé - c'est-à-dire
SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7
Les déclarations individuelles seront rapides, mais les performances globales du système se détérioreront, car elles tueront les ressources partagées.
De plus, il est beaucoup plus difficile d'intercepter les erreurs au moment de la compilation avec SQL dynamique. Si vous utilisez PL/SQL, cela supprime une bonne vérification du temps de compilation. Même lorsque vous utilisez quelque chose comme JDBC (où vous déplacez tout votre code de base de données dans des chaînes - bonne idée !), vous pouvez obtenir des pré-analyseurs pour valider le contenu JDBC. SQL dynamique =test d'exécution uniquement.
Frais généraux
La surcharge de l'exécution immédiate est faible - elle se situe dans les millièmes de seconde - cependant, elle peut s'additionner si cela se trouve à l'intérieur d'une boucle / sur une méthode appelée une fois par objet / etc. J'ai une fois obtenu une amélioration de la vitesse 10x en remplaçant dynamique SQL avec SQL statique généré. Cependant, cela a compliqué le code et n'a été fait que parce que nous avions besoin de vitesse.
