utiliser count dans min

Bonjour, voici la requête que j'ai passer et qui fonctionne tres bien

Code:

---

select count(id) ,id_langue from projet group by id_langue

---

et voici le resultas
http://www10.0zz0.com/2010/10/19/14/408220319.jpg
mon probleme c'est que je veux savoir le min du premier champ
Savez-vous comment je peux faire ?

Code:

---

1 2 3

SELECT MIN(C) FROM ( SELECT count(id) AS C, id_langue FROM projet GROUP BY id_langue ) AS T

---

A +

merci

Il y a une écriture plus courte et vachement plus marrante :

Code:

---

1 2 3 4

SELECT TOP(1) min(count(*)) over() FROM projet GROUP BY id_langue

---

Et y a plein de gens qui vous diront que ça ne peut pas marcher :mouarf:

EDIT: Et pas plus tard que ci plus loin dessous ^^

Petite vision de la concurrence, Oracle Database supporte les agrégats imbriqués :

Code:

---

1 2 3

SELECT min(count(id)) FROM projet GROUP BY id_langue;

---

Oui, comme Sybase, ais cela est totalement illogique !
En effet sur quoi porte le GROUP BY ?
Normalement il devrait porter sur les deux agrégats et la requête devrait être équivalente à :

Code:

---

1 2 3

SELECT count(id) FROM projet GROUP BY id_langue;

---

Car un min appliqué au même groupage c'est un min sur une seule valeur !

C'est pourquoi ceci est totalement interdit par la norme SQL !

A +

C'est une facilité d'écriture qui fait exactement la même chose que votre première requête.

L'agrégat interne prend en compte le group by, l'agrégat externe tout ce résultat.

C'est très peu utilisé, car d'une part méconnu et d'autre part ça prête plus à confusion qu'autre chose.

Au niveau du plan d'exécution on économise juste l'étape de la création de la vue imbriquée.

Citation:

---

Envoyé par Waldar

Petite vision de la concurrence, Oracle Database supporte les agrégats imbriqués :

Code:

---

1 2 3

SELECT min(count(id)) FROM projet GROUP BY id_langue;

---

---

Le query que j'ai donné fonctionne tout à fait sur SQL Server :ccool:

Désolé de vous contredire :

Code:

---

1 2 3

SELECT min(count(id)) FROM projet GROUP BY id_langue;

---

SQL Server 2008 :
Msg*130, Niveau*15, État*1, Ligne*1
Impossible d'exécuter une fonction d'agrégation sur une expression comportant un agrégat ou une sous-requête.

SQL Server 2005 :
Msg*130, Niveau*15, État*1, Ligne*1
Impossible d'exécuter une fonction d'agrégation sur une expression comportant un agrégat ou une sous-requête.

SQL Server 2000 :
Serveur*: Msg 130, Niveau 15, État 1, Ligne 1
Impossible d'exécuter une fonction d'agrégation sur une expression comportant un agrégat ou une sous-requête.

MORALITÉ : faut pas abuser du jus de citron !

a +

Lol non non la requête ne fonctionne pas sur SQL Server..
On a de jolies messages d'erreurs .. cf post de SQLPro

Edit : Oui la requête que tu as donné TOI SergeJack elle fonctionne en effet

++

.. par contre la solution de SQLPro est plus performante si le nombre de projets est important par langue.

++

Citation:

---

Envoyé par Sergejack

EDIT: Et pas plus tard que ci plus loin dessous ^^

---

Pas compris votre edit, où quelqu'un a dit que votre solution ne fonctionnait pas ?

Citation:

---

Envoyé par Waldar

Pas compris votre edit, où quelqu'un a dit que votre solution ne fonctionnait pas ?

---

Ben, Sql pro ;)

Sinon, il est vrai (et attendu) que ma requête est moins rapide, puisque je la construit sur des opérations pensés pour un usage bien plus large que celui que j'en fais.
Néanmoins, la différence de performance est légère et donc, connaître cette formule pourrait bien servir (surtout si on veut tirer le réel parti d'un agrégat avec clause OVER).

En effet la différence n'est pas vraiment flagrante entre les 2 solutions.

++

Citation:

---

Envoyé par Sergejack

Ben, Sql pro ;)

Sinon, il est vrai (et attendu) que ma requête est moins rapide, puisque je la construit sur des opérations pensés pour un usage bien plus large que celui que j'en fais.
Néanmoins, la différence de performance est légère et donc, connaître cette formule pourrait bien servir (surtout si on veut tirer le réel parti d'un agrégat avec clause OVER).

---

Je pense même qu'à terme elle risque d'être plus rapide car les opérateurs de fenêtrage, bien que mécaniquement plus gourmand, sont moins dépendant des lignes globalement manipulées. Mais dans un cas aussi léger il faudra attendre longtemps un énorme volume de ligne pour faire la réelle différence.

A +

Citation:

---

Envoyé par Sergejack

Ben, Sql pro ;)

---

Regardez mieux ;)

Citation:

---

Envoyé par Waldar

Regardez mieux ;)

---

J'avais bien vu.
Sql Pro avait même confondu votre query et le mien (sûr comme le citron que ça ne marchait pas).