Neuste 10 Datensätze ausgeben

[Raffi]

Hallo Leute

Ich habe ne kleine Frage. Ich mache ne Abfrage an eie MySQL Datenbank. Nun wenn er eta 50 Datensätze findet, will ich nur die ersten 10 ausgeben die er findet. wie mach ich das?

danke und gruss
raffi

[Cheatah]

Hi,

Ich habe ne kleine Frage. Ich mache ne Abfrage an eie MySQL Datenbank. Nun wenn er eta 50 Datensätze findet, will ich nur die ersten 10 ausgeben die er findet. wie mach ich das?

mit LIMIT, siehe Doku. Dass "die ersten gefundenen" nicht das geringste mit "die neuesten" zu tun hat, sofern Du nicht nach einem mitgespeicherten Datum sortierst, ist Dir hoffentlich bewusst.

Cheatah

[fastix]

Hi  Raffi, Cheatah!

Dass "die ersten gefundenen" nicht das geringste mit "die neuesten" zu tun hat,

Nun, ein wenig mehr als "nicht das geringste" schon :)
Es werden (bei ansonsten nicht nachträglich sortierten Datentabellen) genau die x ältesten Datensätze ausgegeben.

So hier ein SQL Befehl beispielsweise:

SELECT nr, row1, row2 FROM datentabelle WHERE row1="sonstwas" ORDER BY nr LIMIT 0,10

Wähle Nr, Spalte1, Spalte2 aus Datentabelle wenn Spalte1="sonstwas" sortiert nach nr begrenzt auf die 10 Ergebnisse ab dem ersten.
(Der erste hat die Nummer 0)

Übrigens: (Zum Lernen) Der phpMyAdmin zeigt die SQL- Befehle an. Es ist gelegentlich gut, den zu verwenden und mal hinzuschauen...

fastix&reg:

[Philipp Hasenfratz]

Halihallo fastix

Nun, ein wenig mehr als "nicht das geringste" schon :)
Es werden (bei ansonsten nicht nachträglich sortierten Datentabellen) genau die x ältesten Datensätze ausgegeben.

Das ist fast richtig, mit einer kleinen Bemerkung:
Falls nicht explizit ein ORDER BY angegeben wurde, wird nicht sortiert und die ersten
_gefundenen_ Tupel werden zurückgegeben. Die ersten _gefundenen_ müssen jedoch nicht die
_ältesten_ sein, obwohl das ohne Datensätze zu löschen der Fall ist. Werden Datensätze
gelöscht, wird der Eintrag in der Datei freigegeben und neue Datensätze beanspruchen u.
U. diesen Speicherbereich (Speichermanagement des Tabellentreibers); wenn dies
geschieht, stimmt deine Aussage nicht mehr; da dann auch die neuesten Einträge in den
ersten Speicherbereichen der Datendatei liegen...

Viele Grüsse

Philipp

[Thomas Schmieder]

Hallo,

und wenn nr nichrt automatisch belegt worden ist (autoincrement-key primary), dann ist auch nicht sichergestellt, dass die Nummer irgendwas mit der Historie zu tun hat.

Gute Datenbankdesigner geben allerdings jeder Tabelle einen Primärschlüssel, der in allen Tabellen nach der selben Regel erzeugt wird und nehmen sogar (gegen die Lehrmeinung) Schlüsselredundanzen bzw. direkte Abhängigkeiten zwischen Schlüsseln in Kauf, wenn man mal einen von dieser Regel abweichenden Schlüssel benötigt.

Der Schlüssel sollte z.B. immer ID_<Tablename> heißen und immer ein Autoincrement-Key Primary sein. Dann gibts niemals Irritationen.

Es gibt Datenbanken, die dann auch automatisch nach diesem Schlüssel sortieren, wenn man nichts Anderes angibt. Ob MySQL das tut, weiß ich nicht.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Cheatah]

Hi,

und wenn nr nichrt automatisch belegt worden ist (autoincrement-key primary), dann ist auch nicht sichergestellt, dass die Nummer irgendwas mit der Historie zu tun hat.

auch eine auto_increment-Spalte darf nicht für eine Sortierung missbraucht werden. Der Wert dient *nur und ausschließlich* der Eindeutigkeit.

Gute Datenbankdesigner geben allerdings jeder Tabelle einen Primärschlüssel,

Was?

Der Schlüssel sollte z.B. immer ID_<Tablename> heißen

Nomenklaturen sind lokal. Bei mir heißt eine PK-Spalte beispielsweise immer 'id' und wird aus anderen Tabellen mittels 'ref_tabellenname' referenziert. Übrigens: Wie vergibst Du die Namen, wenn der PK aus mehreren Spalten besteht?

und immer ein Autoincrement-Key Primary sein.

Dies gilt wohlgemerkt nur für MySQL. Die meisten anderen DBMSse kennen ein solches Konzept nämlich nicht.

Dann gibts niemals Irritationen.

Das ist zwar sehr wichtig, es gibt aber mehrere Modelle, die dies leisten.

Es gibt Datenbanken, die dann auch automatisch nach diesem Schlüssel sortieren, wenn man nichts Anderes angibt.

Echt? Welche zum Beispiel? Ist das von bestimmten Bedingungen bei der Abfrage abhängig?

Cheatah

[Thomas Schmieder]

Hallo,

auch eine auto_increment-Spalte darf nicht für eine Sortierung missbraucht werden. Der Wert dient *nur und ausschließlich* der Eindeutigkeit.

Wer sagt das? Das legt der Datenbank-Applikationsentwickler soch selber fest! Ich verstehe hier Deinen ewigen Einwand nicht.

Gute Datenbankdesigner geben allerdings jeder Tabelle einen Primärschlüssel,

Was?

Oh, entschuldige, ich wußte nicht, dass Du nicht dazugehörst.

Der Schlüssel sollte z.B. immer ID_<Tablename> heißen

Nomenklaturen sind lokal. Bei mir heißt eine PK-Spalte beispielsweise immer 'id' und wird aus anderen Tabellen mittels 'ref_tabellenname' referenziert. Übrigens: Wie vergibst Du die Namen, wenn der PK aus mehreren Spalten besteht?

Wie Du Deinen Schlüssel nennst ist mir eigentlich egal. Ich _empfehle_ aus guter Erfahrung den Namen ID_<Tablename> für den Autoincrement-Primary-Key. Bei einem Join muss man dann bezüglich der IDs nicht erst mit Namenskonflikten rumhampeln. Man kann natürlich auch bei jeder Abfrage die vollständigen Bezeichner benutzen: <tablename>.ID

Und Autoincrements können nicht aus mehreren Spalten bestehen. Lies bitte in Zukunft genauer. Wenn man einen Kombinationsschlüssel benötigt, besteht dieser ja i.d.R. aus echten Datenwerten (z.B. Autonummer, Sozialversicherungsnummer, etc...)

Dies gilt wohlgemerkt nur für MySQL. Die meisten anderen DBMSse kennen ein solches Konzept nämlich nicht.

Ich kenne kein DBMS, dass keine Autoincrement-Keys kennt. Nenn mir bitte fünf, wenn Du meinst, dass das die Regel wäre.

Es gibt Datenbanken, die dann auch automatisch nach diesem Schlüssel sortieren, wenn man nichts Anderes angibt.

Echt? Welche zum Beispiel? Ist das von bestimmten Bedingungen bei der Abfrage abhängig?

z.B. der MSSQL-Server, btrieve-scalable-sql, Sybase SQL, Informix SQL, ...

Neujahrs-Grüße aus http://www.braunschweig.de

Tom

[Christian Seiler]

Hallo Tom,

Ich kenne kein DBMS, dass keine Autoincrement-Keys kennt. Nenn mir bitte fünf, wenn Du meinst, dass das die Regel wäre.

Reichen Dir 3 von denen ich es sicher weiß? (Ich vermute, es sind auch _alle_ anderen außer MySQL, aber ich kann es nicht mit Sicherheit sagen)

Oracle, PostgreSQL, Microsoft SQL Server.

Die kennen Sequenzen - das sind aber _keine_ auto_increment-Felder, sondern ein _völlig_ anderes Konzept.

Grüße,

Christian

[Cheatah]

Hi,

auch eine auto_increment-Spalte darf nicht für eine Sortierung missbraucht werden. Der Wert dient *nur und ausschließlich* der Eindeutigkeit.

Wer sagt das? Das legt der Datenbank-Applikationsentwickler soch selber fest!

nein, tut er nicht. Welche Werte eine auto_increment-Spalte erzeugt, hängt vom DBMS ab - es ist (theoretisch, praktikabel wäre das nicht) möglich, dass die nächste MySQL-Version beispielsweise "Lücken füllt", oder dass beim Erreichen des Maximalwertes wieder von vorne an gezählt wird (derzeit wird einfach der letzte Wert ewig wiederholt).

Ich verstehe hier Deinen ewigen Einwand nicht.

Und jetzt? Wenn die Werte nach Deiner Beobachtung (oder gerne auch de facto) derzeit stets ansteigt, dann heißt das noch lange nicht, dass dies verlässlich ist.

Gute Datenbankdesigner geben allerdings jeder Tabelle einen Primärschlüssel,
Was?
Oh, entschuldige, ich wußte nicht, dass Du nicht dazugehörst.

Ich behaupte, ich habe schon ein wenig Ahnung von DB-Layouts. Einige meiner Arbeiten sind jedenfalls mit einigen Millionen Datensätzen in mehreren Dutzend Tabellen und recht intensiven Änderungsraten am Laufen. Es sind Tabellen dabei, die von nirgendwo referenziert sind und in denen teilweise _keine_ Spaltenkombination als PK hinreicht. Es wäre nötig gewesen, eine künstliche PK-Spalte zu erzeugen, welche ausschließlich zu ihrer eigenen Befüllung genutzt worden wäre. Hälst Du das für sinnvoll?

Der Schlüssel sollte z.B. immer ID_<Tablename> heißen
Nomenklaturen sind lokal. Bei mir [...]
Wie Du Deinen Schlüssel nennst ist mir eigentlich egal. Ich _empfehle_ [...]

Ja, da will ich Dich auch nicht dran hindern. Worauf ich hinaus will ist, dass das von Dir angesehene Optimum noch lange nicht das Nonplusultra für jeden anderen sein muss.

ID_<Tablename>

Wenn der Tabellenname von Relevanz ist - bei Joins etwa - dann deshalb, weil mehrere Tabellen im Spiel sind. In dieser Situation ist es empfehlenswert, _alle_ Spaltenzugriffe mit dem Tabellennamen (oder einem Alias) zu kennzeichnen, damit man nicht das DB-Layout auswendig kennen muss, un zu verstehen was da vor sich geht (Stichwort Wartbarkeit). Es heißt dann also ohnehin "<Tablename>.ID". Wenn man sich nur innerhalb einer Tabelle bewegt, ist eh klar, dass es sich um dessen ID handelt, das bedarf keiner Erwähnung.

Bei einem Join muss man dann bezüglich der IDs nicht erst mit Namenskonflikten rumhampeln.

Wie machst Du das bei anderen Spalten, die in unterschiedlichen Tabellen identisch heißen?

Und Autoincrements können nicht aus mehreren Spalten bestehen.

Primary Keys jedoch schon, und es ist keinesfalls zwingend nötig, dass eine der Spalten ein auto_increment ist.

Lies bitte in Zukunft genauer.

Da muss ich jetzt nichts zu sagen, oder?

Wenn man einen Kombinationsschlüssel benötigt, besteht dieser ja i.d.R. aus echten Datenwerten (z.B. Autonummer, Sozialversicherungsnummer, etc...)

Nö, in den meisten bei mir vorgekommenen Fällen waren es Referenzen auf andere ID-Spalten. Insbesondere bei Kreuztabellen.

Dies gilt wohlgemerkt nur für MySQL. Die meisten anderen DBMSse kennen ein solches Konzept nämlich nicht.
Ich kenne kein DBMS, dass keine Autoincrement-Keys kennt.

Interessehalber: Welche kennst Du?

Nenn mir bitte fünf, wenn Du meinst, dass das die Regel wäre.

Siehe Christians Antwort.

Es gibt Datenbanken, die dann auch automatisch nach diesem Schlüssel sortieren, wenn man nichts Anderes angibt.
Echt? Welche zum Beispiel? Ist das von bestimmten Bedingungen bei der Abfrage abhängig?
z.B. der MSSQL-Server, btrieve-scalable-sql, Sybase SQL, Informix SQL, ...

Danke. Worauf ich mit der letzten Frage hinauswollte: Bei welchem Ausführungsplan wird die Sortierung durchgeführt? Eine Sortierung kostet Zeit; und gewöhnlich sind DBMSse (auch) auf Geschwindigkeit getrimmt. Oft reicht es sogar, wenn zunächst die ersten paar gefundenen Datensätze zum Client zurückgeliefert werden, noch ehe das gesamte Resultset feststeht. Wenn erst sortiert werden muss, ist das nicht mehr möglich.

Cheatah

[fastix]

SELECT nr, row1, row2 FROM datentabelle WHERE row1="sonstwas" ORDER BY nr LIMIT 0,10

Kleiner Fehler: das gibt die ersten, also (bei aufsteigender Nummernvergabe) ältesten Datensätze zurück.

SELECT nr, row1, row2 FROM datentabelle WHERE row1="sonstwas" ORDER BY nr DESC LIMIT 0,10

..  Die neuesten 10

nr sollte mit dem extra auto_increment versehen sein. Danach sollte an nr nicht mehr herumgespielt werden...

und das geht so:

CREATE TABLE datentabelle (
  nr bigint(20) NOT NULL auto_increment,
  row1 tinytext,
  row1 tinytext,
  PRIMARY KEY  (nr),
)TYPE=MyISAM;

[fastix]

CREATE TABLE datentabelle (
  nr bigint(20) NOT NULL auto_increment,
  row1 tinytext,
  row1 tinytext,
  PRIMARY KEY  (nr),
)TYPE=MyISAM;

weil ich nochwas vergessen habe:

INSERT INTO datentabelle (nr, row1, row2) VALUES (10, "text1", "text2);

führt bei MySQL zu einem Fehler.

INSERT INTO datentabelle (nr, row1, row2) VALUES ("", "text1", "text2");
_oder_
INSERT INTO datentabelle (nr, row1, row2) VALUES (NULL, "text1", "text2");

(Das steht NULL ohne Textbegrenzer!)

weist dann nr einen Wert automatisch zu. Eine Änderung ist nicht sinnvoll. Das aber gänge...

So, jetzt hätten wir das umfassen gelöst :)

fastix

[Cheatah]

Hi,

Dass "die ersten gefundenen" nicht das geringste mit "die neuesten" zu tun hat,

Nun, ein wenig mehr als "nicht das geringste" schon :)

nein, eben nicht.

Es werden (bei ansonsten nicht nachträglich sortierten Datentabellen) genau die x ältesten Datensätze ausgegeben.

Es werden die ersten zehn gefundenen ausgegeben, ohne eine bestimmte Reihenfolge. Wenn das bei Dir die zehn neuesten sind, hat Deine Tabelle offenbar noch nicht besonders viel Bewegung gehabt, das DBMS noch keine Platzoptimierung durchgeführt usw.

Die Datensätze einer Tabelle sind _immer_ unsortiert. Wenn Du im SELECT-Statement keine Sortierung angibst, ist die Reihenfolge des Ergebnisses _zufällig_. In Deinem Fall sind es zufällig die letzten.

Cheatah