SQL: DISTINCT und RRN?

[BenderD]

@Baldur:
bist du da sicher mit der RRN? Ich habe das noch als die physikalische Record Number der ersten Datei im Hinterkopf, die er am Wickel hat, kann also durchaus auch bei unterschiedlicher Zugriffsstrategie von einer anderen Table gezogen werden! Im übrigen führt RRN zu Full Table scans.

Naj, das mit dem Pessimizer, schreiben und lesen soll ja auch Spass machen, ich bin durchaus ein Anhänger davon grob granulare Anforderungen an die Datenbank zu adressieren und den Rest der Query Engine zu überlassen und nur dann dran rumzufummeln, wenn es wirklich zu langsam ist; im statistischen Mittel trifft der Automatismus bessere Entscheidungen als der Programmierer, lediglich das selektive Gedächtnis des letzteren lässt das anders erscheinen!

@Akku:
Ich finde solche Rätsel zu anstrengend, das ist Zeit raubend und klarere Fragen ermöglichen bessere Antworten.

mfg

Dieter Bender

RRN liefert nur die temporäre Satznummer und ist keine reguläre SQL-Funktion.

Deswegen nennt Dieter diesen ja auch "Pessimizer".

Übrigens:
Mit RRN verhindert man mit Sicherheit eine temporäre Kopie (meistens nur ein Auszug) der Daten in den Internspeicher (bzw. *QUERYnnnn in QTEMP).

[Fuerchau]

Dieter:
Für den Moment stimmt das mit der RRN, aber leider gibt es Anwendungen, die Änderungen an Sätzen mit Delete/Insert realisieren, und dann REUSEDLT(*YES) !
Und wie gesagt, RRN verhindert eine temporäre Kopie von Daten auch für das Ergebnis.

[Akku]

Guten Morgen, hatte etwas Urlaub und komme deshalb erst jetzt wieder dazu, in Ruhe ins Forum zu sehen.

Wahrscheinlich ist der Optimizer also der Grund, warum das RRN() in einem Fall mit in das DISTINCT einfließt und im anderen Fall nicht.

Vielen Dank für die geduldigen Erklärungen.

Viele Grüße,
Akku