Fragwürdige SQL-Praxis - Reihenfolge nach ID statt Erstellungszeit

Question

So habe ich eine interessante Frage, die ich nicht sicher bin, ist ein "Hack" oder nicht. Ich habe einige Fragen durchgesehen, aber kein Duplikat gefunden, also ist es hier. Grundsätzlich muss ich wissen, ob dies unzuverlässig ist oder als schlechte Praxis angesehen wird.

Ich habe eine sehr einfache Tabelle mit einer eindeutigen automatisch inkrementieren ID und einem created_at Zeitstempel.

+-----------+--------------------+ 
| id  |created_at   | 
+-----------+--------------------+ 
| 1   |2012-12-11 20:35:19 | 
| 2   |2012-12-12 20:35:19 | 
| 3   |2012-12-13 20:35:19 | 
| 4   |2012-12-14 20:35:19 | 
+-----------+--------------------+ 

Beide Säulen (vereinfachte Version meines Problems, das Konzept in Frage zu klären) werden dynamisch hinzugefügt, so dass es, dass ein neues gesagt werden kann, ‚Einfügen‘ wird IMMER eine größere ID und IMMER haben ein größeres Datum.

ZIEL - bestellen

SELECT * FROM tablename 
ORDER BY created_at DESC 

SOLUTION ZWEI in absteigender Reihenfolge eine Abfrage, die Aufträge nach Datum - sehr einfach die von created_at um

SOLUTION ONE absteigend geordnet Ergebnisse greifen - Eine Abfrage, die nach ID in absteigender Reihenfolge sortiert

SELECT * FROM tablename 
ORDER BY id DESC 

Wird Lösung zwei als schlechte Praxis angesehen? Oder ist Lösung zwei der richtige Weg, Dinge zu tun. Jede Erklärung Ihrer Überlegungen wäre sehr hilfreich, da ich versuche, das Konzept zu verstehen und nicht einfach eine Antwort zu bekommen. Danke im Voraus.

Answer 1

In der typischen Praxis können Sie fast immer davon ausgehen, dass eine Autoinkrement-ID so sortiert werden kann, dass Sie die Datensätze in der Erstellungsreihenfolge (in beide Richtungen) erhalten. Sie sollten jedoch beachten, dass dies in Bezug auf Ihre Daten nicht als tragbar gilt. Sie können Ihre Daten in ein anderes System verschieben, in dem die Schlüssel neu erstellt werden, aber die Daten created_at sind identisch.

Es gibt tatsächlich eine ziemlich gute StackOverflow discussion dieser Ausgabe.

Die grundlegende Zusammenfassung ist die erste Lösung, Bestellung von created_at, gilt als Best Practice. Achten Sie jedoch darauf, das Feld created_at richtig zu indizieren, um die beste Leistung zu erzielen.

Answer 2

Es gibt ein paar Unterschiede zwischen den beiden Optionen.

---

Die erste ist, dass sie unterschiedliche Ergebnisse geben können.

Der Wert created_at ist möglicherweise von der Zeit abhängig, die auf dem Server eingestellt wird, die Spalte id bleibt davon jedoch unberührt. Wenn die Zeit rückwärts eingestellt wird (entweder manuell oder automatisch durch die Zeitsynchronisierungssoftware), könnten Sie Datensätze erhalten, die später eingefügt wurden, aber mit Zeitstempeln, die vor Datensätzen liegen, die früher eingefügt wurden. In diesem Fall erhalten Sie eine andere Reihenfolge, abhängig davon, welche Spalte Sie bestellen. Welche Reihenfolge Sie für "richtig" halten, liegt ganz bei Ihnen.

---

Die zweite ist Leistung. Es ist wahrscheinlich schneller zu ORDER BY Ihre clustered index.

Wie der Clustered Index Up Abfragen Beschleunigt

eine Zeile durch den gruppierten Index Zugriff ist schnell, weil die Zeilendaten auf der gleichen Seite ist, wo der Index-Suche führt.

Standardmäßig ist der gruppierte Schlüssel der Primärschlüssel, in Ihrem Fall vermutlich die Spalte id. Sie werden wahrscheinlich feststellen, dass ORDER BY id etwas schneller ist als ORDER BY created_at.

Answer 3

Primärschlüssel, insbesondere vom Ersatztyp, stellen normalerweise keine sinnvollen Daten dar, abgesehen davon, dass ihre bloße Funktion darin besteht, eindeutig identifizierbare Datensätze zuzulassen. Da Daten in diesem Fall aussagekräftige Daten darstellen, die außerhalb ihrer primären Funktion Bedeutung haben, würde ich sagen, dass das Sortieren nach Daten hier ein logischerer Ansatz ist.

Answer 4

Bestellung nach ID-Bestellungen von Insertion Bestellung.

Wenn Sie Anwendungsfälle haben, bei denen das Einfügen verzögert werden kann, z. B. ein Stapelprozess, müssen Sie nach created_at bestellen, um nach Zeit zu sortieren.

Beide sind akzeptabel, wenn sie Ihre Bedürfnisse erfüllen.

Answer 5

Sie sollten sich nicht auf ID verlassen, außer dass sie eine Zeile eindeutig identifiziert. Es ist eine willkürliche Zahl, die nur zufällig der Reihenfolge entspricht, in der die Datensätze erstellt wurden.

Sagen Sie bitte diese Tabelle

ID creation_date 
1 2010-10-25 
2 2010-10-26 
3 2012-03-05 

In diesem Fall haben, statt creation_date Arbeiten auf ID sortieren.

Jetzt in der Zukunft erkennen Sie, oh, hoppla, müssen Sie das Erstellungsdatum von Datensatz ID # 2 bis 2010-09-17 ändern. Ihre Art ID verwendet jetzt die Datensätze in der gleichen Reihenfolge berichten:

1 2010-10-25 
2 2010-09-17 
3 2012-03-05 

obwohl mit dem neuen Datum sie sein sollten:

2 2010-09-17 
1 2010-10-25 
3 2012-03-05 

Kurzversion: Verwenden Datenspalten für den Zweck, dass sie erstellt. Verlassen Sie sich nicht auf Nebenwirkungen der Daten.