Pouvez sélectionner * utilisation jamais être justifiée?

Question

J'ai toujours prêché à mon développeurs SELECT * est mauvais et doit être évitée comme la peste.

Existe-il des cas où il peut être justifié?

Je ne parle pas de l' COUNT(*) - dont la plupart des optimiseurs peut comprendre.

Modifier

Je parle du code de production.

Et un très bon exemple, j'ai vu de cette mauvaise pratique est un héritage application asp utilisé select * dans une procédure stockée et utilisée ADO d'une boucle sur les enregistrements retournés, mais les colonnes de l'index. Vous pouvez imaginer ce qui est arrivé lorsqu'un nouveau champ a été ajouté quelque part autre que la fin de la liste de champs.

Answer 1

Je suis très heureux à l'aide de * dans les déclencheurs d'audit.

Dans ce cas, il peut effectivement être un avantage, car il permettra de s'assurer que si des colonnes sont ajoutées à la base de la table, il déclenche une erreur donc il ne faut pas oublier de gérer cela à la vérification de déclenchement et/ou de la vérification de structure de table.

(Comme dotjoe) je suis également heureux de l'utiliser dans les tables dérivées et de la colonne d'expressions de table. Si j'ai habituellement le faire dans l'autre sens.

WITH t
     AS (SELECT *,
                ROW_NUMBER() OVER (ORDER BY a) AS RN
         FROM   foo)
SELECT a,
       b,
       c,
       RN
FROM   t; 

Je suis la plupart du temps familier avec SQL Server et il y a au moins l'optimiseur a aucun problème à reconnaître que seules les colonnes a,b,c sera nécessaire et l'utilisation de l' * dans la table interne de l'expression ne cause pas de surcharge inutile de les récupérer et de jeter les colonnes inutiles.

En principe, SELECT * doit être bien en vue que c'est la dernière SELECT à partir de la vue où il devrait être évité toutefois dans SQL Server, cela peut entraîner des problèmes comme il stocke les métadonnées de colonne de points de vue qui n'est pas automatiquement mis à jour lorsque les tables sous-jacentes du changement et de l'utilisation de * peut conduire à la confusion et des résultats incorrects à moins d' sp_refreshview est exécuté pour mettre à jour ces métadonnées.

Answer 2

Il existe de nombreux scénarios où SELECT * est la solution optimale. L'exécution de requêtes ad-hoc dans Management Studio juste pour avoir une idée des données que vous travaillez avec. Interrogation de tables où vous ne connaissez pas les noms de colonne encore parce que c'est la première fois que vous avez travaillé avec un nouveau schéma. Bâtiment jetables rapide n'dirty outils pour faire une migration ou l'exportation de données.

Je serai d'accord que dans le "bon" développement, vous devriez éviter - mais il y a beaucoup de scénarios où le "bon" développement n'est pas nécessairement la solution optimale à un problème d'entreprise. Les règles et les meilleures pratiques sont grands, aussi longtemps que vous savez quand vous les briser. :)

Answer 3

Je vais l'utiliser dans la production lorsque l'on travaille avec des expressions de table communes. Mais, dans ce cas, il n'est pas vraiment select *, parce que je l'ai déjà précisé les colonnes de la CTE. Je ne veux pas indiquer de nouveau dans le final de la sélectionner.

with t as (
    select a, b, c from foo
)

select t.* from t;

Answer 4

Aucun que je peux penser, si l'on parle de code en direct.

Les gens disent qu'il fait de l'ajout de colonnes plus facile à développer (de sorte qu'ils obtiennent automatiquement retourné et peut être utilisé sans modification de la procédure Stockée) ont aucune idée sur l'écriture d'un code optimal/sql.

Je ne jamais l'utiliser lors de l'écriture de requêtes ad-hoc qui ne seront pas réutilisés (la découverte de la structure d'une table, l'obtention de certaines données lorsque je ne suis pas sûr de ce que les noms de colonne sont).

Answer 5

Je pense que l'utilisation d' select * en exists clause est approprié:

select some_field from some_table 
where exists 
 (select * from related_table [join condition...])

Certaines personnes aiment à utiliser select 1 dans ce cas, mais ce n'est pas élégant, et il ne faut pas acheter toutes les améliorations de performances (début de l'optimisation de frappe à nouveau).