SQL nächster Datensatz

[nnos]

Hallo..

ich suche den SQL befehl, der mir eine Datensatz weiter geht.. warscheinlich suche ich nicht richtig. aber er ist für mich einfach unauffindbar..

gruss nnos

[Daniela Koller]

Hi nnos

ich suche den SQL befehl, der mir eine Datensatz weiter geht.. warscheinlich suche ich nicht richtig. aber er ist für mich einfach unauffindbar..

Sowas macht keinerlei Sinn, Datensätze haben keine Reihenfolge, es kann demnach keinen nächsten geben. Du solltest genauer beschreiben was du tun willst und mit welchen Tools (Datenbanksystem und Programmiersprache).

Gruss Daniela

[Chris (C)]

Hallo,

natürlich gibt es auch bei SQL einen "nächsten Datensatz", allerdings nicht in pfysikalischer reihenfolge, da SQL-Datenbanken sich nicht in die Speicherung reinreden lassen. Die speichern die Sätze sowieso nicht in einer geschlossenen Struktur sondern in Bäumen, teilwweise für jedes Feld einen eigenen.

Du müsstest also definieren, was Du unter "nächster" verstehst und SQL das einfach mitteilen.

• der nächste in der Erfassung (->Timestamp)

• der nächste in der Index-Reihenfolge
    -- ohne Duplicates
    -- mit Duplicates (kompliziert)

• unter Berücksichtigung der Datendynamik (Dynaset, dynamische Abfragen)

• mit vorheriger Selektion (Snapshot, statisches (Zwischen-)Ergebnis)

usw...

Liebe Grüße

Chris ()

[Philipp Hasenfratz]

Halihallo Chris

natürlich gibt es auch bei SQL einen "nächsten Datensatz", allerdings nicht in pfysikalischer reihenfolge, da SQL-Datenbanken sich nicht in die Speicherung reinreden lassen. Die speichern die Sätze sowieso nicht in einer geschlossenen Struktur sondern in Bäumen, teilwweise für jedes Feld einen eigenen.

Ich glaube du sprichst von den Indizies, nicht von den Datensätzen, denn diese liegen
wirklich in einer linearen, sequenziellen Reihenfolge (ggf. mit Löchern) vor. Bäume
dienen nur des schnelleren Auffindens, die Datenbank holt jedoch nur bedingt Werte
daraus. Der eigentliche Wert eines Attributes (Spalte, evtl. Zeile kommt darauf an, wie
man sich das Zeug visuell darstellen lässt ;)), worauf die Datenbank "ohne Index"
zugreift liegt wo anders.

Ok, Ok, um noch einen "Fehler" im letzten Satz auszuräumen: Ein Attribut hat keinen Wert,
lediglich Instanzen (man hört des öfteren mal "Zellen") davon. Um dies mal noch korrekter
auszudrücken und ewaigen Verbesserungsvorschlägen vorzubeugen ;)

Du müsstest also definieren, was Du unter "nächster" verstehst und SQL das einfach mitteilen.

• der nächste in der Erfassung (->Timestamp)
• der nächste in der Index-Reihenfolge
    -- ohne Duplicates
    -- mit Duplicates (kompliziert)
• unter Berücksichtigung der Datendynamik (Dynaset, dynamische Abfragen)
• mit vorheriger Selektion (Snapshot, statisches (Zwischen-)Ergebnis)

Ja, das ist richtig. Dennoch ein kleiner Exkurs:

Datenbanksysteme relationaler Natur (RDBMS) definieren die Daten als Multimengen. In
Mengen gibt es keine Ordnung und somit bietet die darauf angewendete relationale Algebra
keine Möglichkeit eine Ordnung zu schaffen. Der Begriff der Ordnung wurde erst mit SQL,
der deskriptiven Abfragesprache für RDBMSe, eingeführt und dies könnte man sogar als
Bug bezeichnen. Nur wird dieser "Bug" eigentlich von allen als Feature gesehen. Oder
sehe ich das falsch?

Das Problem ist, dass einige ein vorschnelles Posting verfassen und sich diesen
Überlegungen nicht wirklich bewusst sind, deshalb Danielas berechtigter Einwurf (schätze
ich mal *g*).

Viele Grüsse

Philipp

[Daniela Koller]

Hi Philipp, Chris

natürlich gibt es auch bei SQL einen "nächsten Datensatz", allerdings nicht in pfysikalischer reihenfolge, da SQL-Datenbanken sich nicht in die Speicherung reinreden lassen. Die speichern die Sätze sowieso nicht in einer geschlossenen Struktur sondern in Bäumen, teilwweise für jedes Feld einen eigenen.

Ich glaube du sprichst von den Indizies, nicht von den Datensätzen, denn diese liegen
wirklich in einer linearen, sequenziellen Reihenfolge (ggf. mit Löchern) vor.

Ehm, sogar Datensätze können ganz grundsätzlich völlig verstreut liegen, es ist nichtmal gegeben, dass die überhaupt auf der selben Festplatte liegen, das hängt sehr vom DBMS ab und von Optionen mit denen man das DBMS füttert, sie liegen auch nicht zwingend in der zeitlichen Reihenfolge auf der Platte. Ich kenne allerdings keine einzige Datenbank, die einen Datensatz aufsplittet.

Das Problem ist, dass einige ein vorschnelles Posting verfassen und sich diesen
Überlegungen nicht wirklich bewusst sind, deshalb Danielas berechtigter Einwurf (schätze
ich mal *g*).

Mir unklar, ob der Poster vielleicht einfach nur bei PHP, oder irgend einer anderen Sprache, einen Datensatz weiter (MYSQL_FETCH_ROW) will.

Und selbst wenn ich davon ausgegangen wäre, dass der Poster die Frage im Zusammenhang mit ORDER BY gedacht hat, hätte die Frage zuwenig Informationen geboten um zu helfen. Limit ist hochgradig DBMS spezifisch, bei MySQL gehts mit LIMIT n,m, bei PostGreSQL gehts ganz ähnlich aber zusätzlich braucht man noch das Schlüsselwort Offset, bei Oracle gehts nochmal anders und bei MSSQL nochmal.

Gruss Daniela

[Chris (C)]

Hi,

Ehm, sogar Datensätze können ganz grundsätzlich völlig verstreut liegen, es ist nichtmal gegeben, dass die überhaupt auf der selben Festplatte liegen, das hängt sehr vom DBMS ab und von Optionen mit denen man das DBMS füttert, sie liegen auch nicht zwingend in der zeitlichen Reihenfolge auf der Platte. Ich kenne allerdings keine einzige Datenbank, die einen Datensatz aufsplittet.

Das ist alles Definitionssache. Man könnte behaupten, dass z.B. MySQL-Tabellen, die variante Datentypen (enum, Text, Blob, ...) enthalten, nicht vollständig normalisiert sind und das die Datanbank daher nachholt. Aber Text und Blobs werden tatsächlich nicht in einem geschlossenen Record-Bereich gespeichert. Sie werden irgendwo auf der Platte abgelegt und nur referenziert.

Und selbst wenn ich davon ausgegangen wäre, dass der Poster die Frage im Zusammenhang mit ORDER BY gedacht hat, hätte die Frage zuwenig Informationen geboten um zu helfen. Limit ist hochgradig DBMS spezifisch, bei MySQL gehts mit LIMIT n,m, bei PostGreSQL gehts ganz ähnlich aber zusätzlich braucht man noch das Schlüsselwort Offset, bei Oracle gehts nochmal anders und bei MSSQL nochmal.

Und MSSQL kennt auch nur einen Parameter, was das Ganze sehr unhandlich macht.

Man sollte vielleicht bemerken, dass ein Datenmodellierer selber etwas dafür tun muss, dass Datensätze nach bestimmten Kriterien sortierbar und abarbeitbar sind. Wenn man kein Feld mit Zeitkriterium einbaut, kann man später auch nicht mehr feststellen, in welcher Reihenfolge die Sätze bearbeiet wurden. Da gab es hier mal eine Diskussion, in der darauf hingewiesen wurde, dass noch nicht einmal ein Autoincrement-Primary-Key Gewähr dafür ist, die Erfassungsreiehenfolge wieder gerstellen zu können, da das DBMS ggf. frei gewordene Schlüssel wieder verwendet (was ich mir allerdings verbitten möchte *gg*)

Grüße

Chris (C)

[Simone]

Hi

$SQL = "SELECT * FROM $Tabelle WHERE Deine Einschränkung ORDER BY Deine Suche limit Deine Werte";

limit ist der Schlüssel und mit "Deine Werte" kannst Du Ihn erhöhen

Simone

[Michael Schröpl]

Hi Simone,

$SQL = "SELECT * FROM $Tabelle WHERE Deine Einschränkung ORDER BY Deine Suche limit Deine Werte";

wer garantiert Dir, daß die Anzahl der Datensätze dieser Tabelle sich zwischen zwei solchen Statements nicht geändert hat?
Du könntest jeden beliebigen Datensatz auf diese Weise erwischen - insbesondere vielleicht sogar den "nächsten" ...

Viele Grüße
      Michael