Pour répondre à votre question, il faut la décortiquer un peu :
SELECT * présente 3 principaux types d'inconvénients :
- Maintenance du code :l'utilisation de SELECT * réduit la lisibilité des tables/requêtes complexes et peut causer des problèmes lorsqu'une application cliente attend un certain résultat d'une requête, mais que la table change
- Performances réseau :l'utilisation de SELECT * lors du renvoi des résultats à une application cliente signifie que toutes les colonnes seront renvoyées au client ; si seules certaines de ces colonnes sont utilisées par le client, la bande passante est gaspillée et l'application s'exécute plus lentement qu'elle ne le pourrait.
- Performances du plan d'indexation/requête :dans certaines circonstances, si vous avez une requête qui n'a vraiment besoin de renvoyer que les colonnes qui participent à un index, mais que vous les renvoyez toutes à la place, vous pourriez obtenir des plans de requête bien pires créés par le moteur.
Je ne suis pas sûr de ce que vous entendez par "implication concernant l'interprétation des caractères génériques", mais je suppose que vous ne comprenez pas pourquoi SELECT * est une mauvaise idée - le moteur SQL valide de toute façon les colonnes fournies ; le coût de "l'expansion" du joker est essentiellement de 0.
Une procédure stockée n'est pas vraiment une "unité de code compilée":le plan de requête d'une procédure stockée sera généralement mis en cache après sa première exécution, mais il en va de même pour les instructions SQL ad hoc également dans de nombreuses/la plupart des circonstances.
Maintenant, pour répondre à votre question :Oui , les inconvénients de l'utilisation de SELECT * en SQL ad hoc s'appliquent également, de la même manière, au SQL à l'intérieur d'une procédure stockée.
