Warum fügt SSMS neue Zeilen oben in eine Tabelle ein, nicht unten?

Immer wenn ich in SQL Server Management Studio 2008 eine Zeile manuell in eine Tabelle einfüge (die Datenbank ist SQL Server 2005), wird meine neue Zeile oben in der Liste und nicht unten angezeigt. Ich verwende Identitätsspalten und dies führt zu Dingen wie

id  row
42 first row
1 second row
2 third row

Wenn Zeilen abgerufen und nicht explizit geordnet werden. Dies führt zu einer anderen Darstellung, wenn die Zeilen für die Webanwendung abgerufen werden, und ändert, was eine TOP 1Abfrage zurückgibt.

Ich weiß, ich kann order bysie, aber warum passiert das? Die meisten meiner Daten werden über eine Webanwendung eingefügt. Alle Einfügungen aus dieser Anwendung führen zu einer First-In-First-Out-Bestellung, z. Befindet sich auf dem Server oder im Management Studio eine Einstellung, die diese falsche Reihenfolge verursacht?

In der SQL-Welt ist die Reihenfolge keine inhärente Eigenschaft einer Datenmenge. Daher erhalten Sie von Ihrem RDBMS keine Garantie dafür, dass Ihre Daten in einer bestimmten Reihenfolge - oder sogar in einer konsistenten Reihenfolge - zurückkehren, es sei denn, Sie fragen Ihre Daten mit einer ORDER BYKlausel ab.

Von Craig Freedman :

Die Kombination von TOP mit ORDER BY fügt der Menge der zurückgegebenen Zeilen Determinismus hinzu. Ohne ORDER BY hängt die Menge der zurückgegebenen Zeilen vom Abfrageplan ab und kann sogar von Ausführung zu Ausführung variieren.

Verwenden ORDER BYSie diese Option immer, wenn Sie eine klar definierte und konsistente Reihenfolge in Ihrer Ergebnismenge erwarten. Verlassen Sie sich niemals darauf, wie Ihre Datenbank die Zeilen auf der Festplatte speichert (z. B. über einen Clustered-Index), um eine bestimmte Reihenfolge der Daten in Ihren Abfragen zu gewährleisten.

Nur um die anderen Antworten zu ergänzen: Eine Tabelle ist per Definition eine ungeordnete Menge von Zeilen. Wenn Sie keine ORDER BYKlausel angeben , kann SQL Server die Zeilen in der Reihenfolge zurückgeben, die er für am effizientesten hält. Dies fällt häufig nur mit der Reihenfolge des Einfügens zusammen, da die meisten Tabellen einen Clustered-Index für Identität, Datum und Uhrzeit oder andere monoton ansteigende Spalten aufweisen. Sie sollten dies jedoch genau so behandeln: ein Zufall. Es kann sich mit neuen Daten, einer Statistikaktualisierung, einem Ablaufverfolgungsflag, Änderungen an maxdop, Abfragehinweisen, Änderungen an der Verknüpfung oder Where-Klauseln in der Abfrage, Änderungen am Optimierer aufgrund eines Service Packs / kumulativen Updates / Hotfixes / Upgrades ändern. Verschieben der Datenbank auf einen anderen Server usw. usw.

Mit anderen Worten, und ich weiß, dass Sie die Antwort bereits kennen, aber es kann nicht genug gesagt werden:

Wenn Sie sich auf die Reihenfolge einer Abfrage verlassen möchten, fügen Sie IMMER hinzu ORDER BY .

Dies liegt daran, dass die Tabelle (höchstwahrscheinlich) eine Heap-Tabelle ist und nicht indiziert ist. Machen Sie die ID-Spalte a PRIMARY KEYsowie IDENTITY. SQL Server speichert die Daten physisch basierend auf den Indizes. Wenn id beispielsweise ein Clustered-Index (wie ein Primärschlüssel) wäre, würden die Daten physisch in der Reihenfolge der IDs gespeichert und auf diese Weise auch ohne eine Abfrage zurückgegeben eine ORDER BYKlausel. Andernfalls ist die Reihenfolge der Zeilen für die Datenbank überhaupt nicht wichtig. Folglich ist es keine gute Praxis , eine Anwendung von der Reihenfolge der Zeilen in der Datenbank abhängig zu machen (und auch davon, ob sich die Spalten in einer bestimmten Reihenfolge befinden). Die Anwendung muss mit allen Schlüsseln arbeiten, die sich in der Datenbank befinden, um Zeilen zu identifizieren.