... das ist eines dieser Märchen, die ungeprüft von einem zum anderen weiter erzählt werden (sorry, dass es dich jetzt mit meiner Antwort erwischt). Dieser Mythos geht zurück auf einen Artikel von Dan Cruikshank, der vom IBM Marketing weiter verbreitet wird (http://www-03.ibm.com/systems/resour...e_DDS_SQL.pdf), obwohl er der DB2/400 ein verheerendes Zeugnis ausstellt: das würde nämlich bedeuten, dass bei einer beschädigten Tabelle aus einer SQL Tabelle jeder beliebige Dreck hochkäme...
Ich habe mir das bereits bei erscheinen mal näher angesehen:
- die Maschine hungert (muss eine alte Möhre sein) die braucht für einen read so um die 3 Millisekunden
- CPU Verbrauch ist bei SQL und DDL ziemlich identisch (und welche Ressource braucht Prüfung?)
- die Verarbeitungszeit ist klar durch "Waits" dominiert (99%), was in diesem Fall I/O bedeutet.
Schlussfolgerung: die Begründung für die Zeitunterschiede ist glasklar falsch (Dummfug, der Dummfugigsten Sorte, würde Fred Feuerstein sagen). Was näher liegt ist, dass sich die Blockgrößen beim lesen unterscheiden, ist aber spekulativ.

Kommen wir zu den Zeitunterschieden und deren Relevanz:
Auffallend sind auf den ersten Blick die seltsamen Skalierungen und die unterschlagenen Differenzen. Die Gesamtlaufzeit der Testprogramme differiert von 21 zu 25 sec, der Teil für die Leseschleife von 15 zu 26. Selbst wenn ich jetzt annehme, dass die Unterschieder korrekt und typisch wären, ergibt sich im vorliegenden Fall, dass aus den 2 Sekunden (lesen ohne order by) 1,5 Sekunden würden, die 20 Sekunden würden dann auf 19,5 Sekunden abnehmen.

Konsequenz 1: glaube keiner Benchmark, die du nicht selber gefälscht hast!
Konsequenz 2: Es gibt keine Patentrezepte (die wären dann schon eingebaut)

D*B

Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
Noch ein kleiner Tipp: Egal ob mit SQL oder Native I/O bei DDS Tabellen werden die Daten nur beim Lesen geprüft und bei SQL-Tabellen nur beim Schreiben. Da mehr gelesen wird als geschrieben sind SQL-Tabellen auch Performanter.