Il semblerait que l'une des réponses qui implémentent une clause ORDER BY dans la solution manque le point ou ne comprend pas réellement ce que TOP vous renvoie.
TOP renvoie un jeu de résultats de requête non ordonné qui limite le jeu d'enregistrements aux N premiers enregistrements renvoyés. (D'un point de vue Oracle, cela revient à ajouter un où ROWNUM <(N + 1).
Toute solution qui utilise une commande peut renvoyer des lignes qui sont également renvoyées par la clause TOP (puisque cet ensemble de données n'était pas ordonné en premier lieu), en fonction des critères utilisés dans l'ordre par
L'utilité de TOP est qu'une fois que l'ensemble de données atteint une certaine taille N, il arrête de récupérer les lignes. Vous pouvez avoir une idée de ce à quoi ressemblent les données sans avoir à les récupérer toutes.
Pour implémenter BOTTOM avec précision, il faudrait extraire l'ensemble de données sans ordre, puis restreindre l'ensemble de données aux N enregistrements finaux. Cela ne sera pas particulièrement efficace si vous avez affaire à d'énormes tables. Cela ne vous donnera pas nécessairement non plus ce que vous pensez demander. La fin de l'ensemble de données peut ne pas être nécessairement "les dernières lignes insérées" (et ne le sera probablement pas pour la plupart des applications DML intensives).
De même, les solutions qui implémentent un ORDER BY sont malheureusement potentiellement désastreuses lorsqu'il s'agit de grands ensembles de données. Si j'ai, disons, 10 milliards de disques et que je veux les 10 derniers, il est assez stupide de commander 10 milliards de disques et de sélectionner les 10 derniers.
Le problème ici, c'est que BOTTOM n'a pas le sens auquel on pense en le comparant à TOP.
Lorsque des enregistrements sont insérés, supprimés, insérés, supprimés encore et encore et encore, des espaces apparaissent dans le stockage et plus tard, des lignes sont insérées, si possible. Mais ce que nous voyons souvent, lorsque nous sélectionnons TOP, semble être des données triées, car elles peuvent avoir été insérées tôt dans l'existence de la table. Si la table ne subit pas de nombreuses suppressions, elle peut sembler être ordonnée. (par exemple, les dates de création peuvent remonter aussi loin que la création de la table elle-même). Mais la réalité est que s'il s'agit d'une table lourde en suppression, les N lignes TOP peuvent ne pas ressembler du tout à cela.
Donc, l'essentiel ici (jeu de mots) est que quelqu'un qui demande les enregistrements BOTTOM N ne sait pas vraiment ce qu'il demande. Ou, du moins, ce qu'ils demandent et ce que BOTTOM signifie réellement ne sont pas la même chose.
Donc - la solution peut répondre aux besoins commerciaux réels du demandeur ... mais ne répond pas aux critères pour être le BOTTOM.