61 votes

SÉLECTIONNER * SAUF

Existe-t-il un SGBDR qui implémente quelque chose comme SELECT * EXCEPT ? Ce que je cherche, c'est à obtenir tous les champs, à l'exception d'un champ TEXTE/BLOB spécifique, et j'aimerais simplement sélectionner tout le reste.

Presque tous les jours, je me plains à mes collègues de travail que quelqu'un devrait implémenter ceci... C'est terriblement ennuyeux que cela n'existe pas.

Editar: Je comprends la préoccupation de chacun pour SELECT * . Je connais les risques associés à SELECT * . Toutefois, dans ma situation, cette méthode ne serait pas utilisée pour un code de niveau production, ni même pour un code de niveau développement, mais uniquement pour le débogage, lorsque j'ai besoin de voir toutes les valeurs facilement.

Comme je l'ai dit dans certains commentaires, l'endroit où je travaille est strictement une boutique en ligne de commande, tout se fait par ssh. Cela rend difficile l'utilisation d'outils graphiques (les connexions externes à la base de données ne sont pas autorisées), etc etc.

Merci quand même pour les suggestions.

0 votes

Le mot-clé EXCEPT existe dans SQL Server, mais il n'est pas destiné à être utilisé comme vous le souhaitez dans votre question. Il effectue une UNION DE DIFFÉRENCE entre deux jeux de résultats pour vous donner un jeu de résultats des "enregistrements" qui existent dans le premier jeu de résultats mais n'existent pas dans le deuxième jeu de résultats.

7 votes

C'est nul que ça n'existe pas.

1 votes

38voto

Jasmine Points 2139

Comme d'autres l'ont dit, ce n'est pas une bonne idée de faire cela dans une requête car cela peut poser des problèmes lorsque quelqu'un modifie la structure de la table à l'avenir. Cependant, il existe un moyen de le faire... et je n'arrive pas à croire que je suis en train de le suggérer, mais dans l'esprit de répondre à la VRAIE question...

Faites-le avec du SQL dynamique... cela fait toutes les colonnes sauf la colonne "description". Vous pourriez facilement transformer cela en une fonction ou une procédure stockée.

declare @sql varchar(8000),
    @table_id int,
    @col_id int

set @sql = 'select '

select @table_id = id from sysobjects where name = 'MY_Table'

select @col_id = min(colid) from syscolumns where id = @table_id and name <> 'description'
while (@col_id is not null) begin
    select @sql = @sql + name from syscolumns where id = @table_id and colid = @col_id

    select @col_id = min(colid) from syscolumns where id = @table_id and colid > @col_id and name <> 'description'
    if (@col_id is not null) set @sql = @sql + ','
    print @sql
end

set @sql = @sql + ' from MY_table'

exec @sql

17 votes

Et dans l'esprit de répondre à la vraie question, vous gagnez le prix.

3 votes

Je peux en fait penser à plusieurs raisons pour lesquelles vous pourriez avoir besoin de faire ça sans être fou. De plus, c'était une question intéressante, indépendamment des problèmes, c'était juste amusant à comprendre :)

3 votes

Tout d'abord, je vous remercie d'avoir répondu à la question plutôt que de vous prononcer sur la question de savoir si la personne devrait faire la chose ou non. Un scénario de base pour faire cela serait la création d'une vue, dont vous voulez qu'elle récupère les colonnes de la table sous-jacente si elles changent, et que vous utiliserez dans d'autres instructions de sélection qui sélectionnent des colonnes spécifiques.

25voto

Paul Dixon Points 122033

Créez une vue sur la table qui n'inclut pas les colonnes du blob.

2 votes

+1 : c'est tout à fait raisonnable - et aucun SELECT * n'est autorisé ici aussi.

3 votes

Nécessite de modifier la vue si la table source change. Si vous devez utiliser SELECT * sur cette vue, autant sélectionner les colonnes que vous voulez vraiment pour commencer.

1 votes

Cela vous évite cependant de taper ces colonnes encore et encore. Pour un développeur, ce n'est pas une mauvaise idée pour le débogage.

9voto

billinkc Points 23616

DB2 le permet. Les colonnes ont un attribut/spécificateur de Hidden .

De la Documentation sur les syscolumns

HIDDEN
CHAR(1) NON NUL AVEC LA VALEUR PAR DÉFAUT 'N'.
Indique si la colonne est implicitement masquée :

P Partiellement caché. La colonne est implicitement masquée par SELECT *.

N Non caché. La colonne est visible pour toutes les instructions SQL.

Créer une documentation sur les tables Dans le cadre de la création de votre colonne, vous devez spécifier l'attribut IMPLICITLY HIDDEN modificateur

Un exemple de DDL de Colonnes implicitement cachées suit

CREATE TABLE T1
(C1 SMALLINT NOT NULL,
C2 CHAR(10) IMPLICITLY HIDDEN,
C3 TIMESTAMP)
IN DB.TS;

Nous laissons aux futurs lecteurs le soin de déterminer si cette capacité est un facteur déterminant pour l'adoption de DB2.

5voto

onedaywhen Points 24594

Existe-t-il un SGBDR qui implémente quelque chose comme SELECT * EXCEPT

Oui ! Le langage véritablement relationnel Tutoriel D permet d'exprimer la projection en termes d'attributs à supprimer plutôt que d'attributs à conserver, par ex.

my_relvar { ALL BUT description }

En fait, c'est l'équivalent du SQL SELECT * es { ALL BUT } .

Votre proposition pour SQL est intéressante, mais j'ai entendu dire qu'elle avait déjà été soumise au comité de la norme SQL par le groupe des utilisateurs et rejetée par le groupe des vendeurs :(.

Il a également été demandé explicitement pour SQL Server mais la demande a été classée comme "non réparable".

2voto

Otávio Décio Points 44200

Restez loin de SELECT *, vous vous attirez des ennuis. Toujours spécifier exactement les colonnes que vous voulez. Il est en fait assez rafraîchissant que la "fonctionnalité" que vous demandez n'existe pas.

0 votes

Heureusement, nos tables ne changent presque jamais. Je pense à cela spécifiquement pour les problèmes de débogage, où j'ai besoin de tous les autres champs, à l'exception du BLOB.

0 votes

Dans ce cas précis, je suis d'accord pour dire que ce serait bien de l'avoir.

0 votes

Le mot clé ici est presque . De même, tout bon outil SQL vous permettra de cliquer et de choisir ce que vous voulez sans polluer le langage avec de tels engins.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X