DB2 classe-t-il les données par clé primaire

J'ai récemment eu une discussion avec un collègue qui tentait de supprimer les clauses order by d'une requête de production, car la colonne order by était la même que la clé primaire .

Après une longue discussion au cours de laquelle j'ai essayé d'expliquer qu'il ne pouvait pas garantir un ordre basé sur la clé primaire, la conclusion finale était qu'il n'allait pas pousser pour que les requêtes MSSQL soient modifiées.
Mais il allait toujours modifier les requêtes DB2.

Je n'ai pas pu trouver immédiatement un article réfutant le fait que DB2 commande les requêtes par la clé primaire, et je me demande actuellement si oui ou non.

Ma question est donc de savoir comment DB2 ordonne une requête s'il n'y a pas de clause order by? Utilise-t-il la clé primaire?
Comment pouvez-vous garantir que les données soient correctement commandées, sans clause de tri, dans un système parallèle?

Non, votre collègue a tort.

Tous les proroduits SQL - SGBD qui se comportent conformément aux normes SQL - ne garantissent pas que le résultat d'une sortie de requête sera ordonné de quelque manière que ce soitORDER BY , sauf s'il existe une clause dans la requête .

Comme le mentionnent les documents IBM DB2 :

La commande est effectuée conformément aux règles de comparaison décrites dans Éléments de langage. La valeur nulle est supérieure à toutes les autres valeurs. Si votre spécification de commande ne détermine pas une commande complète, les lignes avec des valeurs en double de la dernière clé de tri identifiée ont un ordre arbitraire. Si vous ne spécifiez pas ORDER BY, les lignes de la table de résultats ont un ordre arbitraire.

Comme cela a été souligné dans la réponse de ypercube, lorsqu'il n'y a pas de ORDER BYclause, il n'y a pas d'ordre défini .

Ce que je voudrais ajouter, c'est qu'il est important de réaliser que SQL est vraiment une abstraction, il ne spécifie pas étape par étape ce que doit faire le SGBD mais spécifie plutôt vos exigences du résultat final.

Cela implique que si les données sont déjà recherchées de manière à garantir le bon ordre, c'est parce que le SGBD a décidé d'une telle stratégie et il saura alors déjà qu'aucun travail de tri supplémentaire n'est nécessaire pour répondre aux exigences de la ORDER BYclause. .

D'un autre côté, si vous ne spécifiez pas que la commande est importante pour vous (même si elle l'est réellement?), Le SGBD en tiendra compte et s'il trouve une stratégie différente plus efficace pour trouver les bonnes données dans une autre commande, elle profitera du fait que vous ne vous êtes apparemment pas soucié de la commande. (La stratégie choisie pourrait également très bien changer au fil du temps, en fonction de l'augmentation de la quantité de données dans les tableaux pertinents, les correctifs logiciels, etc.)

C'est-à-dire que la suppression de la ORDER BYclause a très peu d'avantages (taille de requête légèrement plus petite) mais potentiellement d'énormes inconvénients si la commande est réellement importante. Surtout, car cela pourrait très bien fonctionner avec l'ensemble de données de test et passer les tests d'acceptation uniquement pour causer de graves problèmes sur toute la ligne.