Le Row_Number() OVER (ORDER BY (SELECT 1)) l'astuce ne devrait PAS être considéré comme un moyen d'éviter de modifier l'ordre des données sous-jacentes. C'est seulement un moyen d'éviter que le serveur effectue un tri supplémentaire et inutile (il peut toujours effectuer le tri mais cela coûtera le moins cher possible par rapport au tri par colonne).
Toutes les requêtes dans le serveur SQL DOIVENT ABSOLUMENT avoir un ORDER BY clause dans la requête la plus externe pour que les résultats soient ordonnés de manière fiable et garantie.
Le concept de "conservation de l'ordre d'origine" n'existe pas dans les bases de données relationnelles. Les tables et les requêtes doivent toujours être considérées comme non ordonnées jusqu'à et à moins qu'un ORDER BY la clause est spécifiée dans la requête la plus externe.
Vous pouvez essayer la même requête non ordonnée 100 000 fois et la recevoir toujours avec le même ordre, et ainsi en venir à croire que vous pouvez vous fier à cet ordre. Mais ce serait une erreur, car un jour, quelque chose va changer et ça n'aura pas l'ordre que vous attendez. Par exemple, lorsqu'une base de données est mise à niveau vers une nouvelle version de SQL Server, cela a entraîné la modification de l'ordre de nombreuses requêtes. Mais cela ne doit pas être un si grand changement. Quelque chose d'aussi simple que l'ajout ou la suppression d'un index peut entraîner des différences. Et plus encore :Installation d'un service pack. Partitionner une table. Création d'une vue indexée incluant la table en question. Atteindre un point de basculement où un balayage est choisi au lieu d'une recherche. Et ainsi de suite.
Ne vous fiez pas aux résultats à ordonner sauf si vous avez dit "Serveur, ORDER BY ".
