Les groupes dans Linq à Sql sont-ils déjà triés par Count() décroissant?

Question

Il semble donc, mais je ne trouve pas de documentation définitive sur le sujet.

Ce que je demande est si le résultat de cette requête:

from x 
in Db.Items 
join y in Db.Sales on x.Id equals y.ItemId 
group x by x.Id into g 
orderby g.Count() descending 
select g.First() 

est toujours la même que la requête suivante:

from x 
in Db.Items 
join y in Db.Sales on x.Id equals y.ItemId 
group x by x.Id into g 
select g.First() 

Notez que la seconde requête permet de Linq décider de la commande du groupe, que la première requête définit comme nombre vendu, du plus au moins. Mes tests ad-hoc semblent indiquer que Linq trie automatiquement les groupes de cette façon, alors que documentation semble indiquer que l'inverse est vrai - les éléments sont retournés dans l'ordre où ils apparaissent dans le select. Je me dis que s'il est trié de cette façon, l'ajout du tri supplémentaire est inutile et gaspille des cycles, et serait mieux laissé de côté.

Answer 1

Vous le voyez probablement car le résultat de la requête renvoyé par sqlserver est toujours dans le même ordre dans vos tests. Cependant, c'est un sophisme: par définition, les ensembles en SQL n'ont pas d'ordre à moins qu'il ne soit explicitement spécifié avec un ORDER BY. Donc, si vos requêtes n'ont pas d'ordre par ordre, vos ensembles pourraient ressembler à ce qu'ils sont commandés, mais ce n'est pas le cas, il se peut que dans les cas de bord l'ordre est différent (par exemple lorsque le serveur doit charger des pages de la table dans un ordre différent en raison de contraintes de mémoire ou autrement). Donc règle générale: si vous voulez une commande, vous devez en spécifier une.

Answer 2

Le regroupement LINQ ne garantit pas une telle chose. Bien que cela puisse fonctionner pour cette circonstance particulière, cela pourrait ne pas fonctionner dans une autre situation. Évitez de vous fier à cet effet secondaire. Par ailleurs, si la sortie est vraiment intentionnellement triée par SQL Server en raison d'index cluster ou quelque chose, l'ajout d'une clause ORDER BY ne nuira pas car l'optimiseur de requête doit être assez intelligent pour savoir que le résultat est déjà trié, donc vous ne perdrez rien.

Answer 3

Si les spécifications ne vous garantissent pas une commande, vous devriez considérer cela comme étant accidentel et sujet à modification avec n'importe quelle nouvelle version du logiciel.

Et ne le prenez pas à moins

a) que vous avez mesuré et cela fait une différence significative

b) vous êtes prêt à surveiller, tester et changer de retour (partout) après chaque petit changement dans votre environnement logiciel.