nächstes & vorgänger Element anzeiegen

[hdmnf]

hallo

Ich möchte mit dieser Abfrage den Vorgänger Datensatz ermitteln, aber die Abfrage bringt mehrere Ergebnisse.

Abfrage im phpmyadmin ausgeführt:
SELECT contentnr from content where katnr = 1 and contentnr < 23

Ergebnis:
Zeige Datensätze 0 - 1 (2 insgesamt, die Abfrage dauerte 0.0003 sek.)
SQL-Befehl: SELECT contentnr
FROM content
WHERE katnr =1
AND contentnr & lt;

23


Ergebnis:
Ich bekomme zwei Datensätze mit der 12 und der 22 als contentnr angezeigt. Das sind genau die beiden Vorgänger, aber ich hätte hier nur den einen Datensatz mit der Nr. 22 haben wollen, weil das der Vorgänger zum 23er ist.





Die Abfrage zum Nachfolger funktioniert wunderbar, dass ist genau die gleiche wie die des Vorgängers nur das Größerzeichen umgedreht. (hier bekomme ich immer nur den dirket nachfolegenden angezeigt)


Was mache ich hier nur falsch??????????

[awsdcom]

Re: Nachfolger &amp; Vorgänger Element anzeiegen -&gt; Fehler? (mehrere Datens.)

Original geschrieben von hdmnf
SELECT contentnr from content where katnr = 1 and contentnr < 23

SELECT contentnr
FROM content
WHERE katnr = 1
AND contentnr < 23
ORDER BY contentnr DESC
LIMIT 1

..versuch das mal!

[hdmnf]

funzt! KLASSE!!! VIELEN DANK!!!

[PHP-Desaster]

na, was sagt mein Prof immer zum Maximum ermitteln durch sortieren? ^^
Performanter ist:

SELECT max( contentnr )
FROM content
WHERE katnr = 1
AND contentnr < 23

[ghostgambler]

Naja, dank Optimizer, sollte das eigentlich äquivalent performant sein - Nachteil bei MAX ist allerdings, dass man keine anderen Spalten selektieren kann, d.h. man müsste dann gleich wieder mit Sub-Query arbeiten und dass wiederum würde ich sagen ist definitiv langsamer in mysql~
Ansonsten würde ich aber auch zu der Max-Variante tendieren - ist kürzer~

[PHP-Desaster]

Naja, bei einer geringen Anzahl von Datensätzen wird der Aufwand kaum auseinander gehen, jedoch hat eine Sortierung den Aufwand O(n·log(n)), das Ermitteln des größten Elementes nur O(n).
Nimm 20.000 Datensätze:

Sortieren: ~80.000 (wenn man den log10 nimmt, normalerweise sogar log2, also noch höher)
Maximum: ~20.000

[ghostgambler]

Ich gehe davon aus, dass der Optimizer die beiden Queries, die beide sowieso nur auf dem Index laufen, gleich abarbeitet. (Kann mich natürlich auch irren - wäre ja nicht das erste Mal, dass der Optimizer nicht wirklich optimiert...)

[onemorenerd]

Das MAX(contentnr) allein wäre praktisch überhaupt kein Aufwand (O(c*Baumtiefe)), wenn contentnr Präfix eines Index ist.
Da aber die Where-Klausel zuerst erfüllt sein muß, wäre so ein Index nutzlos.

Also wenn diese Query wirklich nur über Indizes läuft, wie ghostgambler sagt, dann muß es entweder
a) zwei separate Indizes für katnr und contentnr geben oder
b) einen mehrwertigen Index (katnr.contentnr).

Der TO hat soweit ich sehe gar keine Angaben zu vorhandenen Indizes gemacht. Er sollte aber darüber nachdenken, denn PHP-Desaster könnte Recht haben.

Wenn a) oder b) erfüllt sind, kann bzw. sollte nicht optimiert werden.
Doch wenn keine geeigneten Indizes vorhanden sind, muß der Optimizer ran. Tja und ob der nun besonders pfiffig ist oder nicht, die Query hat nur einen Freiheitsgrad: die Kommutativität von AND.
Für eine Bewertung der beiden alternativen Auswertungsfolgen bräuchte der Optimizer Wissen über die Werteverteilung einzelner Attribute. AFAIK sammelt MySQL aber solche Daten nicht.

Fazit: Auf den Optimizer kommt es bei dieser Query nicht an. Der TO braucht die richtigen Indizes.


BTW: Ich bin mir nicht sicher, ob MySQL weiß, dass ORDER BY + LIMIT 1 das selbe ist wie MAX ... aber wahrscheinlich werden unterschiedliche Ausführungspläne für beide Queries erzeugt, weil eine Konvertierung in MAX() voraussetzt, dass bestimmte Randbedingungen erfüllt sind (Spalten im SELECT u.v.m.). Die Prüfung dieser Randbedingungen kann u.U. sehr aufwändig sein und wurde in MySQL schätzungsweise nicht implementiert.
Ist halt ein DBS für "einfache Queries" und "kleine Datenbestände", kein Bedarf für intensives Optimieren.