...die jeweils letzte Zeile einer Gruppe

[free.runn3r]

Hi,

gegeben sei folgende Tabelle:

itemId|orderId
0815|0663741
0815|0543943
0815|0137592
4711|0775232
4711|0637004

Wie könnte ich diese Ausgabe erreichen?

itemId|orderId
0815|0137592
4711|0637004

LG;-)

 

[akretschmer]

...

test=*# select * from freerunner ;
 item | order_id
------+----------
  815 |  663741
  815 |  543943
  815 |  137592
 4711 |  775232
 4711 |  637004
(5 rows)

test=*# select item, min(order_id) from freerunner group by item order by item;
 item |  min
------+--------
  815 | 137592
 4711 | 637004
(2 rows)

 

[free.runn3r]

Hi,

danke für das Abbilden. Aber das wäre ja zu einfach Ich suche nicht die kleinste order_id je item, sondern die jüngste order_id je item. Das heißt, ich benötige den der Tabelle zuletzt hinzugefügten Datensatz für jede order_id. Ich habe es schon mit ROWNUM und verschiedenen Subqueries probiert. Ich komme einfach nicht zum Ziel.

LG;-)

 

[akretschmer]

Mit Deiner Tabellenstruktur nicht machbar: du hast keinen Timestamp, der dafür verwendet werden könnte.

 

[ukulele]

SQL speichert die Information, welcher Datensatz wann eingefügt wurde nur, wenn man es entsprechend vorsieht. Die ROW_NUMBER() Funktion nummeriert nur durch und selbst wenn du die "wahre" Zeilennummer (Reihenfolge der Daten auf dem physischen Datenträger) irgendwie ausliest so ist sie weder zuverlässig noch muss sie etwas mit der schreibreihenfolge zu tun haben.

 

[free.runn3r]

Hi, meine Tabelle ist natürlich nur ein erdachtes Beispiel für das schnelle Verständnis meines Problems. Aber wenn ich

select * from freerunner;

verwende, so gehe ich davon aus, dass er mir die Daten in der Reihenfolge anzeigt, wie sie der Tabelle hinzugefügt wurden? Oder irre ich da? Verwende ich dann ferner

select item, order_id from freerunner
order by item, rownum desc;

so erhalte ich zwar immer noch mehrere order_id-Einträge je item, aber zumindest ist der letzte Eintrag je item nun an erster Stelle. Ich wollte das Ergebnis des Selects in einem Subquery mit einer anderern Abfrage verbinden. Das geht aber leider nicht. Dann muss ich die Daten eben in der eigentlichen C#-Anwendung zusammenführen. Da gibt es dann die Linq-Methode .GetFirst(), dir mir die jeweils erste Übereinstimmung liefert.

LG;-)

 

[akretschmer]

so gehe ich davon aus, dass er mir die Daten in der Reihenfolge anzeigt, wie sie der Tabelle hinzugefügt wurden? Oder irre ich da?

Ja.

 

[ukulele]

Ohne ORDER BY Klausel ist die Ausgabe per Definition zufällig. Das DBMS wird zwar beim selben Tabellenstand immer die selbe Reihenfolge liefern (zumindest MSSQL tut das), muss es aber nicht und verlassen sollte man sich da auch nicht drauf.

 

[Distrilec]

@ukulele Du widersprichst dir gerade selbst... Die Wörter "immer" und "muss es aber nicht" zusammen zu verwenden sorgt meistens nur für weitere Verwirrung

Grundsätzlich ist es so: Wenn man keine Reihenfolge vorgibt, spuckt die Datenbank die Daten so wie gelesen aus. Wie die Daten gelesen werden ist dabei von vielen unterschiedlichen Faktoren abhängig... Dabei gibt es zwei große Gruppen:
Einmal die Anfrage der Datenbank und einmal der eigentliche Lesevorgang von der Festplatte.

Jetzt nur mal als kleines Beispiel:
Bei der Anfrage der Datenbank wird meistens der selbe Datensatz zur selben Zeit angefragt, einfach weil man meistens einen Index nutzt (der dann nunmal eine Art "implizite" Reihenfolge darstellt) oder weil die Datenbank wirklich einfach sagt "fang vorne an und hör hinten auf"

Wobei hingegen beim eigentlichen Lesevorgang das OS (oder was auch immer die physikalischen Datenträger verwaltet) die Reihenfolge vorgibt.
Wenn Die Datenbank sagt ich hätte gerne Datensätze A, B, C dein OS aber merkt es wäre kostengünstiger erst C dann A und dann B zu lesen, dann werden die Daten auch in der Reihenfolge C, A, B an die Datenbank zurückgegeben.
Nur wenn du jetzt auch eine Reihenfolge vorgegeben hast, nimmt die Datenbank noch eine Sortierung vor... Ansonsten kommen die Daten wie gelesen an den Client zurück.

(In der Realität ist es wesentlich komplizierter... Das hier soll nur einen SEHR groben Überblick geben...)

D.h. man kann sagen im großen und ganzen ist die Reihenfolge meistens gleich. Es ist aber eben nicht sichergestellt

 

[akretschmer]

D.h. man kann sagen im großen und ganzen ist die Reihenfolge meistens gleich. Es ist aber eben nicht sichergestellt

Angenommen, Du hast eine sehr große Tabelle mit 100 Millionen Zeilen. Client A fragt nach 'select * from tabelle'. Will also ALLE sehen. Die DB hat grade mal 10 Datensätze ausgeliefert, da kommt Client B - und fragt dasselbe. Und wieder ohne Sortierung.

Was ist hier sinnvoll aus Sicht der DB?

PG optimiert hier z.B. so, daß B ab Record 11 mit an den Leseprozess von A angeklemmt wird, bekommt also zuerst Record 11 bis 100 Million, und dann noch hinten dran geklatscht 1-10. Damit spart sich die DB das parallele Lesen von 100 Millionen - 10 Datensätzen. Der Gewinn ist enorm. Die Sortierung aber im Eimer. Da keine Sortierung gewünscht war aber völlig ok.

 

[Distrilec]

@akretschmer Man lese den fett-markierten, unterstrichenen und vergrößerten Teil... Den ich extra vor das Fazit geschrieben habe, damit er auch besonders ins Auge sticht...

Allerdings kann ich dir nicht sagen wie Oracle das handelt... So tief bin ich da nicht drinn...

Ich kann mir allerdings nicht vorstellen das Oracle sich da genauso verhält... Hauptsächlich wegen der Concurrency...
Die Daten die man sich mit einem Statement holt sind immer konsistent für eine bestimmte Zeit... D.h. die User müssten das Query genau zur selben Zeit anfragen, damit man die gleichen Daten verwenden kann

 

[akretschmer]

@Distrilec : das ging nicht gegen Dich, sondern eher als Bestätigung deiner Aussage. ;-)

 

[ukulele]

Unter den selben Voraussetzungen wird die DB die Anfrage immer gleich beantworten. Sie muss das aber nicht, weil es nicht spezifiziert ist. Ich finde nicht, das sich das widerspricht.

 

[Distrilec]

@ukulele Ist aber immernoch nur ein Teil der Wahrheit... Weil eben nicht nur die DB arbeitet... Es sei dein man hat ne InMem-DB am Laufen... Dann ist aber sowieso alles anders...