tombe
Erfahrenes Mitglied
Genau, seit nun rund 5 Jahren versucht gondor vergebens dieses Problem zu lösen und hat es bisher nicht geschafft.
Tabelle sortieren. Wie?
- Themenstarter gondor
- Beginndatum
Genau, seit nun rund 5 Jahren versucht gondor vergebens dieses Problem zu lösen und hat es bisher nicht geschafft.
Moin tombe,
Aber er wird sich bestimmt freuen wie doll, wenn er jetzt endlich die durchschnittlichen Schneeflockengrößen in Großropperhausen in den Vor-Silvesternächten Anno 2004 chronologisch sortiert speichern kann.
Grüße
Biber
Aber er wird sich bestimmt freuen wie doll, wenn er jetzt endlich die durchschnittlichen Schneeflockengrößen in Großropperhausen in den Vor-Silvesternächten Anno 2004 chronologisch sortiert speichern kann.
Grüße
Biber
Hallo, Forum!
Eine gescheite (tm) Datenbank kann die Daten anhand eines INDEX sortiert ausgeben. Die Reihenfolge der Daten in einer Datenbanktabelle ist Sache des Datenbankservers und NICHT vorhersagbar. Wenn es Produkte gibt, die diese Funktion unterstützen, ist das sicher schön, aber letztendlich eine Besonderheit, die sich ausserhalb der Standards für relationale DBMSe bewegt.
Das heisst im Klartext: Wer sortierte Daten aus einer Datenbank will, _MUSS_ ein ORDER BY angeben. Sinn eines Datenbankservers ist es, eine Abstraktionsschicht für die Datenhaltung bereitzustellen. Eine Ausnahme bilden hier lediglich embedded Datenbanken, die kein SQL sprechen und "von Hand" eingelesen werden müssen.
Eine Tabelle, die häufig abgefragt wird, kann man i.d.R. bei der Anlage passend konfigurieren. Es gilt hier prinzipiell, dass Indizes in Richtung der Sortierung angelegt werden. Zumindestens ORACLE, POSTGRESQL und DB2 unterstützen das sogenannte CLUSTERING von Tabellen, welche die Datenhaltung in der Tabelle in Bezug zu einem existierenden Index optimiert (Bei MYSQL dürfte das Storage-Engine-spezifisch sein).
Es gilt darüber hinaus, dass die DB-Server bzw. die Sitzungskonfiguration ebenfalls die Performance beeinflussen kann. Wenn man beispielsweise den Bufferpool bei INNODB Tabellen groß genug wählt, liegt eine häufig frequentierte Tabelle im Buffer cache und wird pfeilschnell im Speicher sortiert.
Wenn die Datenmenge so groß ist (>10Mio Records), dass eine optimierte Abfrage zur Sortierung herhalten muss, kann man auf das Clustering oder auch auf Partitionierungsfeatures zurückgreifen (was nur was bringt, wenn die Datenmenge nach irgendwas eingeschränkt wird und nach irgendwas partitioniert werden kann).
Gerade bei MySQL sollte man die Menge der selektierten Columns klein halten und wirklich nur das in die Selektion nehmen, was man braucht, da die Menge der Spalten massiv Einfluss auf die Abfrage- und Sortierperformance nimmt.
just my 2 cents.
Grüße
gore
Eine gescheite (tm) Datenbank kann die Daten anhand eines INDEX sortiert ausgeben. Die Reihenfolge der Daten in einer Datenbanktabelle ist Sache des Datenbankservers und NICHT vorhersagbar. Wenn es Produkte gibt, die diese Funktion unterstützen, ist das sicher schön, aber letztendlich eine Besonderheit, die sich ausserhalb der Standards für relationale DBMSe bewegt.
Das heisst im Klartext: Wer sortierte Daten aus einer Datenbank will, _MUSS_ ein ORDER BY angeben. Sinn eines Datenbankservers ist es, eine Abstraktionsschicht für die Datenhaltung bereitzustellen. Eine Ausnahme bilden hier lediglich embedded Datenbanken, die kein SQL sprechen und "von Hand" eingelesen werden müssen.
Eine Tabelle, die häufig abgefragt wird, kann man i.d.R. bei der Anlage passend konfigurieren. Es gilt hier prinzipiell, dass Indizes in Richtung der Sortierung angelegt werden. Zumindestens ORACLE, POSTGRESQL und DB2 unterstützen das sogenannte CLUSTERING von Tabellen, welche die Datenhaltung in der Tabelle in Bezug zu einem existierenden Index optimiert (Bei MYSQL dürfte das Storage-Engine-spezifisch sein).
Es gilt darüber hinaus, dass die DB-Server bzw. die Sitzungskonfiguration ebenfalls die Performance beeinflussen kann. Wenn man beispielsweise den Bufferpool bei INNODB Tabellen groß genug wählt, liegt eine häufig frequentierte Tabelle im Buffer cache und wird pfeilschnell im Speicher sortiert.
Wenn die Datenmenge so groß ist (>10Mio Records), dass eine optimierte Abfrage zur Sortierung herhalten muss, kann man auf das Clustering oder auch auf Partitionierungsfeatures zurückgreifen (was nur was bringt, wenn die Datenmenge nach irgendwas eingeschränkt wird und nach irgendwas partitioniert werden kann).
Gerade bei MySQL sollte man die Menge der selektierten Columns klein halten und wirklich nur das in die Selektion nehmen, was man braucht, da die Menge der Spalten massiv Einfluss auf die Abfrage- und Sortierperformance nimmt.
just my 2 cents.
Grüße
gore
Moin Alex F & gorefest,
...allerdings würde ich gern vor dem Schliessen noch ein paar Fussnoten anmerken für künftige MitleserInnen.
a) irreführend ist mawus Kommentar vom Feb 2005 "Hier ist was in SQL ....ALTER TABLE table_name ORDER BY Spalte;"
Dieses Feature hat nur (afaik) MySQL jemals ins Angebot genommen - ist kein SQL-Standard.
Und eigentlich wie gorefest schrieb auch nichts mit den SQL-Konzepten Vereinzubarendes.
b) Und auch bei MySQL ist es mehr und häufiger im Bugreport zu lesen als in der Doku.
In der deutschen Doku taucht es ab spätestens Version 5.1 nicht mehr auf MySQL ALTER TABLE dt . In der englischen Doku 5.1 wird es noch erwähnt.
Dort steht auch, wie gorefest diskutiert hat, dass es keinen Sinn macht z.b. bei der innoDB, sofern PRIMARY KEYS oder NOT NULL-Constraints verwendet werden, da dieses Physisch-analog-zu-logischer-Sortierung-Ablegen (Clustered Index) automatisch so praktiziert wird.
c) Und auch in allen Beiträgen, die ich eben bezüglich Nutzen und Sinnhaftigkeit dieses Features (wenn es denn syntaktisch funktioniert) überflogen habe ist die vorherrschende Bewertung "Thumps down".
Grüße
Biber
Jepp, unterstütze ich, allerdings...
...allerdings würde ich gern vor dem Schliessen noch ein paar Fussnoten anmerken für künftige MitleserInnen.
a) irreführend ist mawus Kommentar vom Feb 2005 "Hier ist was in SQL ....ALTER TABLE table_name ORDER BY Spalte;"
Dieses Feature hat nur (afaik) MySQL jemals ins Angebot genommen - ist kein SQL-Standard.
Und eigentlich wie gorefest schrieb auch nichts mit den SQL-Konzepten Vereinzubarendes.
b) Und auch bei MySQL ist es mehr und häufiger im Bugreport zu lesen als in der Doku.
In der deutschen Doku taucht es ab spätestens Version 5.1 nicht mehr auf MySQL ALTER TABLE dt . In der englischen Doku 5.1 wird es noch erwähnt.
Dort steht auch, wie gorefest diskutiert hat, dass es keinen Sinn macht z.b. bei der innoDB, sofern PRIMARY KEYS oder NOT NULL-Constraints verwendet werden, da dieses Physisch-analog-zu-logischer-Sortierung-Ablegen (Clustered Index) automatisch so praktiziert wird.
c) Und auch in allen Beiträgen, die ich eben bezüglich Nutzen und Sinnhaftigkeit dieses Features (wenn es denn syntaktisch funktioniert) überflogen habe ist die vorherrschende Bewertung "Thumps down".
Grüße
Biber
