Update per Sql mit externer Datenstruktur

[Fuerchau]

Deshalb verstehe ich die Diskssion hier auch nicht, "FMYFILE UF K DISK" und gut ist.

Die Benutzung einer Funktion beim where führt äusserst selten zu einem Direktzugriff.
Inzwischen kann man für solche Fälle z.T. (z.B. nicht bei RRN) "computed Indizes" verwenden, aber die sind meist doch nicht besonders zu empfehlen.

[andreaspr@aon.at]

Andreas,
auch wenn die Relative Satz-Nr. eindeutig eine Zeile definiert, kann die relative Satz-Nr. vom SQL-Optimizer nicht als Zugriffsweg verwendet werden.
Relative Satz-Nr. sind NICHT Standard-SQL!

Von Zugriffsweg habe ich auch nichts geschrieben. Die DB ermittelt über eine sogenannte "Values List" intern die genaue Adresse.
Es wird jeden falls nicht zwangsläufig ein Table-Scann durchgeführt ... außer man macht sowas wie ...
WHERE RRN(t1) > xxx and RRN(t1) < xxx.

Dass kann man sich auch im Debug oder Visual Explain sehr gut anschauen lassen.

In Oracle z.B. ist es noch schneller. Dort ist die RRN nicht nur eine fortlaufende Nr. sondern beinhaltet auch gleich die Information wo im Speicher sich der Satz befindet.

Aber wie schon gesagt, empfehlen würde ich es trotzdem nicht.

lg Andreas

[mk]

Bei allem SQL,

selbst heute gibt es noch Entwickler die Daten über LF's lesen
und mit der RRN die physische Tabelle schreiben und ändern.:confused:


Gruß
Michael

PS:Kenne Leute die Suibfiles mit update geöffnete
Dateien schreiben :eek:

[Fuerchau]

Nun ja, bzgl. RRN hat sich ja ab V6 wohl was getan.

In native Zugriffen per Chain war so was ja noch z.T. normal, aber in SQL-Zeiten...