SQL: DISTINCT und RRN?

[Akku]

@Fuerchau:
Sofern ich in der View keine Sätze gruppiere (mit GROUP oder DISTINCT) kann ich doch wohl RRN() verwenden?!

@Dieter Bender

Hinweis:
Der Inhalt von „Summenfeld 3” ist für alle 3 bzw. 8 Sätze NULL (undefiniert, da keine Daten gefunden)

1. Select ohne DISTINCT ohne „Summenfeld 3“ -> 8 Sätze (siehe unterste Tabelle)
2. Select ohne DISTINCT mit „Summenfeld 3“ -> 8 Sätze (dito)

3. Select mit DISTINCT ohne „Summenfeld 3“ -> 3 Sätze (siehe erste/zweite Tabelle)
4. Select mit DISTINCT mit „Summenfeld 3“ -> 3 Sätze (dito)

Ergo : Kein Unterschied mit oder ohne „Summenfeld 3“


5. CREATE VIEW abc AS wie 3.
und danach SELECT rrn(abc), abc.* from abc -> 3 Sätze

6. CREATE VIEW abc AS wie 4.
und danach SELECT rrn(abc), abc.* from abc -> 8 Sätze

Ergo : Unterschied, ob mit oder ohne „Summenfeld 3“, obwohl im direkt ausgeführten Fall dasselbe Summenfeld keineswegs zu getrennten Sätzen führt (siehe 4.)

Was konkret sorgt also bei 6. dafür, dass die Sätze getrennt werden?!

RRN()? -> ABER: Dann müssten auch im 5. Fall acht Sätze herauskommen

Ermittlung „Summenfeld 3“? -> ABER: Wieso habe ich dann bei der interaktiven Ausführung (4. Fall) keine Trennung?

Die Art wie SQL im Augenblick arbeitet, finde ich jedenfalls unlogisch, zumal im ähnlich gelagerten „GROUP BY“-Fall obige Selects auf die Views auch verständlicherweise eine Fehlermeldung produzieren würden (sowohl 5. als auch 6.!).

Falls niemand eine andere Erklärung hat, werde ich den vorliegenden Fall also wirklich unter V5R3 ungelöste Probleme mit SELECT DISTINCT verbuchen.

Vielen Dank trotzdem.

[Fuerchau]

Dazu muss man wissen, wie der Optimizer arbeitet.
Häufig wird der eigene SQL intern umgebaut und ergänzt um bessere Ergebnisse zu erzielen.
D.h., dass der SQL aus der VIEW entnommen wird und mit den zusätzleichen Feldern/Where/group/having ergänzt wird.
Folge:
aus
"select rrn(abc), ... from (select distinct ...) abc"
wird
"select distinct rrn(abc), ....."

und siehe da, RRN kann nie distinct sein und somit taucht jeder Satz auf.

Hieran kann man die Probleme von RRN sehr eindeutig erkennen und eben besser mit Schlüsseln arbeiten.
Ein anschliessender "select * from file where rrn(file)=nnn" führt nicht zum direkten Zugriff sondern zum Table-Scan.

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

Hintergrund:
Bei einem Select auf eine View oder LF wird nie das Ergebnis verwendet, da aus Optimizer-Sicht sonst erst die gesamte View verarbeitet werden müsste bevor man zum eigentliche Select käme.
Durch obiges Umbauen kann aber häufiger schneller zugegriffen werden.

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).

[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