Pourquoi SSMS insère-t-il de nouvelles lignes en haut d'un tableau et non en bas?

Chaque fois que j'insère manuellement une ligne dans une table dans SQL Server Management Studio 2008 (la base de données est SQL Server 2005), ma nouvelle ligne apparaît en haut de la liste plutôt qu'en bas. J'utilise des colonnes d'identité et cela se traduit par des choses comme

id  row
42 first row
1 second row
2 third row

Lorsque les lignes sont extraites et ne sont pas explicitement ordonnées. Cela se traduit par une apparence différente lorsque les lignes sont extraites pour l'application Web et modifie le contenu d'une TOP 1requête.

Je sais que je peux order byles faire, mais pourquoi cela se produit-il? La plupart de mes données sont insérées via une application Web, toutes les insertions de cette application entraînent un ordre de premier entré, premier sorti, par exemple la dernière insertion est en bas, donc les identifiants sont tous dans une rangée. Y a-t-il un paramètre sur le serveur ou Management Studio qui provoque ce mauvais ordre?

sql-server ssms identity

— Ben Brocka
source

Comme je l'ai vu parfois, cela dépend de l'ordre du PK sur la façon dont les lignes sont affichées, si vous sélectionnez une seule table. Si vous faites des jointures, cela peut changer en fonction des autres tables PK, FK et index ...

— Guillermo Gutiérrez

Soyez également conscient des scans de manège .

— Michael Green

Réponses:

Dans le monde SQL, l'ordre n'est pas une propriété inhérente d'un ensemble de données. Ainsi, vous n'obtenez aucune garantie de votre SGBDR que vos données reviendront dans un certain ordre - ou même dans un ordre cohérent - sauf si vous interrogez vos données avec une ORDER BYclause.

De Craig Freedman :

La combinaison de TOP avec ORDER BY ajoute du déterminisme à l'ensemble des lignes renvoyées. Sans ORDER BY, l'ensemble des lignes renvoyées dépend du plan de requête et peut même varier d'une exécution à l'autre.

Utilisez toujours ORDER BYsi vous attendez un ordre bien défini et cohérent dans votre jeu de résultats. Ne vous fiez jamais à la façon dont votre base de données peut stocker les lignes sur le disque (par exemple via un index clusterisé) pour garantir un certain ordre des données dans vos requêtes.

— Nick Chammas
source

Juste pour augmenter les autres réponses: un tableau est, par définition, un ensemble de lignes non ordonné. Si vous ne spécifiez pas de ORDER BYclause, SQL Server est libre de renvoyer les lignes dans l'ordre qu'il juge le plus efficace. Cela arrive souvent juste pour coïncider avec l'ordre d'insertion, car la plupart des tables ont un index clusterisé sur l'identité, datetime ou d'autres colonnes à augmentation monotone, mais vous devez le traiter exactement comme ça: une coïncidence. Il peut changer avec de nouvelles données, une mise à jour des statistiques, un indicateur de trace, des modifications de maxdop, des conseils de requête, des modifications de la jointure ou des clauses where dans la requête, des modifications de l'optimiseur en raison d'un service pack / mise à jour cumulative / correctif / mise à niveau, déplacer la base de données vers un autre serveur, etc. etc.

En d'autres termes, et je sais que vous connaissez déjà la réponse, mais on ne peut pas le dire assez:

Si vous souhaitez vous fier à l'ordre d'une requête, ajoutez TOUJOURS ORDER BY .

— Aaron Bertrand
source

Je ne comptais pas dépendre de la commande, mais visuellement, c'est un peu ennuyeux que mes derniers articles insérés soient soudainement au sommet.

— Ben Brocka

Je suppose que c'est parce que vous utilisez Open Table. Dans Management Studio 2008, cette commande a été divisée en "Modifier les n premières lignes" et "Sélectionner les N premières lignes" - lorsque vous choisissez cette dernière, vous êtes libre de modifier la requête résultante, par exemple, supprimer le haut et ajouter une commande par.

— Aaron Bertrand

C'est Management studio 2008, le serveur est 2005, aurait dû être plus clair. Je ne savais pas qu'il y avait une commande "table ouverte", j'ai toujours utilisé les selectdéclarations

— Ben Brocka

Ok, bien le point est toujours là, je comprends que c'est ennuyeux que les données reviennent dans un ordre auquel vous ne vous attendez pas, mais j'espère que maintenant, pourquoi SQL Server ne se soucie pas vraiment de l'ordre auquel vous vous attendez, sauf si vous lui dites que vous vous souciez en ajoutant une clause order by. :-)

— Aaron Bertrand

C'est parce que la table est une table de tas (très probablement) et n'est pas indexée. Faites la colonne ID a PRIMARY KEYainsi que IDENTITY. SQL Server stocke physiquement les données en fonction des index - par exemple, si id était un index clusterisé (tel qu'une clé primaire), les données seraient physiquement stockées dans l'ordre des identifiants et seraient retournées de cette façon dans une requête même sans une ORDER BYclause. Sinon, l'ordre des lignes n'est pas du tout important pour la base de données. Par conséquent, avoir une application dépend de l'ordre des lignes dans la base de données (ainsi que dépendre des colonnes se trouvant dans un certain ordre) n'est pas une bonne pratique. L'application doit fonctionner avec toutes les clés présentes dans la base de données pour identifier les lignes.

— Wil
source

Bon à savoir. Je savais que c'était un indice pour changer l'application à utiliser order by(c'est une application héritée avec beaucoup de mauvaises pratiques) mais je me demandais exactement pourquoi cela s'est produit.

— Ben Brocka

Changer la structure de la table juste pour que SELECT *sans ORDER BY puisse revenir dans le "bon" ordre (mais toujours pas garanti)?

— Aaron Bertrand

Sur un simple SELECT de la table avec un index clusterisé reviendrait dans l'ordre de l'index clusterisé. Ce n'était pas aussi clair que j'aurais dû être que c'était une illustration du moment où les données sont ordonnées physiquement par une colonne particulière, mais ce n'est certainement pas acquis que dans chaque requête, elles seraient renvoyées correctement. Mea culpa.

— Wil

Peu importe ce qu'est l'index clusterisé. SQL Server peut toujours renvoyer la commande en fonction d'un autre index basé sur une grande variété de facteurs. La création d'une clé primaire sur une colonne NE GARANTIT PAS que les sélections sans ordre par reviendront soudainement toujours ordonnées par cette colonne. Pourriez-vous observer cela la plupart du temps? Sûr. Mais ce n'est pas la même chose qu'une garantie. Je n'ai jamais vu d'ours polaire dans ma rue, mais aucun champ de force d'ours polaire ne l'empêche de se produire.

— Aaron Bertrand

Quoi qu'il en soit, mon point de vue était que l'ajout d'une ORDER BYclause est une bien meilleure garantie (même beaucoup moins perturbatrice) que d'apporter des modifications de schéma à la table et d' espérer que l'ordre sera comme vous l'attendez, pour toujours.

— Aaron Bertrand