Discussion :

[alassanediakite]

Salut
Juste une question...
Pourquoi le SELECT ne peut pas prendre de variable?
Une idée de la forme...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT colx, coly, varx, vary,...
VAR varx=expression, vary=expression2
FROM...
WHERE <prédicat sur colonnes>
HAVING <prédicat sur variable>

dans laquelle VAR serait une clause optionnelle de l'instruction SELECT.
Le code que je donne est assez simpliste, mais pensez aux requêtes complexes dans lesquelles on a souvent des répétitions d'expression qu'on voudrais factoriser.
Au passage, MySQL accepte un alias dans le having du genre...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT left(prenom,2) AS initial FROM personne HAVING initial='AL'

Alors pourquoi pas?
@+

[al1_24]

A ma connaissance, cette notation n'est pas prévue dans le standard SQL.
J'ai rencontré ce concept dans Teradata (<expresssion> (named <alias>)) qui précise bien que c'est une spécificité.
Après s'il s'agit juste de factoriser, tu as aussi beaucoup de capacités avec les tables dérivées et les expressions de table.

[alassanediakite]

Salut
Merci de la contribution.
Personnellement, je remplacerai ...

A ma connaissance, cette notation n'est pas prévue dans le standard SQL.

par...

Ce concept n'est pas encore dans le standard SQL.

Qui sait, peut-être que la pertinence se présentera un jour.

J'ai rencontré ce concept dans Teradata (<expresssion> (named <alias>)) qui précise bien que c'est une spécificité.

Ce sont les spécificités qui enrichissent le standard.

Après s'il s'agit juste de factoriser, tu as aussi beaucoup de capacités avec les tables dérivées et les expressions de table.

Les tables dérivées (ou sous-requêtes) et les expressions de tables induisent forcement plus d'une boucle de lecture. Alors que le concept de variable est utilisé à chaque ligne.
@+

[al1_24]

Avec un bon optimiseur, il n'est pas obligatoire que l'usage d''une table dérivée ou une expression de table se traduise en boucle.

[aieeeuuuuu]

Bonjour,

Par ailleurs, HAVING engendre un GROUP BY, (ce qui peut être couteux, donc pas forcément idéal non plus pour les performances lorsqu'il n'est pas nécessaire) mais surtout change la sémantique de la requete.

D'ailleurs, votre requête ne sera pas valide si l'une des variables fait référence a l'une des colonnes de la table sans fonction d'agregation, justement en raison de l'absence de clause GROUP BY explicite.

Enfin, pour ce qui est de MySQL qui accepte cette syntaxe, quand on voit comment il gère la dite clause GROUP BY, je ne pense pas que ce soit une référence à prendre en compte pour ce débat...

[alassanediakite]

Salut

Avec un bon optimiseur, il n'est pas obligatoire que l'usage d''une table dérivée ou une expression de table se traduise en boucle.

Veux-tu dire qu'une requête de la forme...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT ...
FROM (SELECT ... FROM <liste_from_interne>) AS r
WHERE <prédicat>

peut être transformé par un optimiseur sous la forme...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT ... FROM <liste_from_interne> WHERE <prédicat>

Bonjour,

Par ailleurs, HAVING engendre un GROUP BY, (ce qui peut être couteux, donc pas forcément idéal non plus pour les performances lorsqu'il n'est pas nécessaire) mais surtout change la sémantique de la requete.

D'ailleurs, votre requête ne sera pas valide si l'une des variables fait référence a l'une des colonnes de la table sans fonction d'agregation, justement en raison de l'absence de clause GROUP BY explicite.

Enfin, pour ce qui est de MySQL qui accepte cette syntaxe, quand on voit comment il gère la dite clause GROUP BY, je ne pense pas que ce soit une référence à prendre en compte pour ce débat...

admettons cela dans la définition actuelle des choses.
D'où le fait que j'ai separé le WHERE et le HAVING.
L'idée est de ...

1. laisser intact le fonctionnement de WHERE i.e au niveau du moteur de stockage (accès aux blocs binaires de table et d'index)
2. exécuter le HAVING au niveau du moteur de requête (l'espace mémoire de la requête) sans qu'il ne soit forcement lié à un GROUP BY

Merci de vos contributions
@+

[SQLpro]

Salut
Juste une question...
Pourquoi le SELECT ne peut pas prendre de variable?:

Parce que c'est en pure opposition à la logique ensembliste. Il ne faudrait pas une variables scalaire, mais tout simplement un ensemble de données, donc une table; C'est pourquoi le SQL a statuer en proposant les tables temporaires.
Pour info Chris Date a bien indiqué qu'il y avait aussi confusion entre le contenant et le contenu. Car en algèbre relationnelle le même terme désigne les deux.
Dans les langages itératifs, il y a la notion de variable qui est le conteneur et la notion de valeur qui est le contenu.
Chris Date à alors proposer qu'il y ait deux termes : la relation (le contenu) et la "relvar" (variable relationnelle, donc le conteneur).

A +

[alassanediakite]

Salut
SQLpro, la santé ça va?
Que "SQL travaille sur des ensembles", je suis d'accord.
Que "SQL soit un langage déclaratif", je suis d'accord.
Mais que "SQL soit opposé à la réutilisation d'expression déjà calculée" je trouve que c'est mettre un frein au SGBDR.
Merci pour la contribution et 1000% de santé pour toi.
@+

[Mat.M]

Salut
Juste une question...
Pourquoi le SELECT ne peut pas prendre de variable?

parce que c'est tout simplement l'intérêt d'utiliser des langages de procédures stockées comme le PL-SQL (Oracle) ou le Transact SQL (MS SQL-SERVER).
Faire des procédures stockées ça permet d'accéler des traitements sur des bases de données de manière puissance n...

[alassanediakite]

Salut

Justement, le HAVING est forcément lié à un GROUP BY, qu'il soit explicite, ou implicite.

J'ai pas dit le contraire. Je propose une évolution du SELECT (qui je pense l'améliore en temps): permettre au SELECT de réutiliser une expression déjà calculée. Une amélioration qui modifiera le comportement de HAVING.

parce que c'est tout simplement l'intérêt d'utiliser des langages de procédures stockées comme le PL-SQL (Oracle) ou le Transact SQL (MS SQL-SERVER).
Faire des procédures stockées ça permet d'accéler des traitements sur des bases de données de manière puissance n...

Je ne parle ni de boucle, ni de curseur, ni de gestion d'erreur, ni ...
Juste permettre au SELECT de réutiliser une expression déjà calculée puisque c'est cela dont il s'agit!!!.
Si vous voulez on peut poser la question autrement: Pourquoi ne pas permettre au SELECT de réutiliser une expression déjà calculée.
Merci pour vos contributions.
@+

[Mat.M]

Pourquoi ne pas permettre au SELECT de réutiliser une expression déjà calculée

un SELECT ne permet que de retourner les données de colonnes et non de calculer des expressions.
Sauf de calculer des expressions mathématiques et retourner le résultat par exemple on peut faire SELECT 1+1 FROM table..
Ou bien alors je n'ai pas du tout compris ta question il faudrait être plus explicite...

Pourquoi le SELECT ne peut pas prendre de variable?
Une idée de la forme...

pour que le moteur d'interprétation des commandes SQL soit en mesure de faire cela il faudrait qu'il crée une pile de variables dynamique.
Exactement comme lorsqu'on appelle une fonction dans un langage informatique procédural on passe des paramètres à la fonction
Maintenant pourquoi les moteurs d'interprétation SQL ne peuvent pas faire ça je ne sais pas sans doute pour raison de rétro-compatibilité ;
encore une fois il faut utiliser les langages de procédures stockées

dans laquelle VAR serait une clause optionnelle de l'instruction SELECT.

clause optionnelle ? Il faudrait être plus précis

[alassanediakite]

Salut

...encore une fois il faut utiliser les langages de procédures stockées

Ce n'est pas un problème auquel je suis confronté et que cherche à résoudre.
C'est un thème que je propose à débattre: faisabilité et pertinence

...Maintenant pourquoi les moteurs d'interprétation SQL ne peuvent pas faire ça je ne sais pas sans doute pour raison de rétro-compatibilité ;

Là tu es dans le débat et il faut (stp) clarifier ton propos.
@+

[Mat.M]

Là tu es dans le débat et il faut (stp) clarifier ton propos.
@+

?? ce n'est pas faire un débat je ne peux pas faire de débat parce que j'ai précisément écris que je ne savais pas et al1_24 a parlé de compatibilité ; et si tu veux que l'on réponde avec pertinence à tes questions je t'ai posé des questions précisément
Auxquelles tu n'as pas répondu