Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation

[nahpets]

Zitat von Dejan Vu:

Wenn der Server den Index komplett im RAM halten will, der RAM aber zu knapp bemessen ist, hat das imho nichts mit 'schlechtem Design' zu tun (na, vielleicht doch nur ich komm nicht drauf). Da knallt man dann 32GB rein und fertig.

Aber natürlich: Ein Tablescan beibt ein Tablescan.

Ersteres: Stimmt natürlich (meistens), die Hardware muss in der Lage sein, die gestellte Aufgabe zu erledigen.

Zweiteres: Genau hier kann man extrem unperformant arbeiten.
Durch geschickte Umformulierung kann man der Datenbank dabei helfen, die Ergebnismenge von Beginn an möglichst klein zu halten. Weiß nicht, wie oft ich aus der Produktion gehört habe, dass ein Programm soundoslange lief und dann abbrach, weil der Temptablespace mal wieder voll war. Hier schreibt die Datenbank dann halt viel auf die Platte (weil halt ggfls. mal die maximal mögliche Speichermenge in der Hardware steckt) und das ist nun mal nicht der schnellste Weg. Wenn man ihr aber dabei hilft, die Datenmenge von vorneherein klein zu halten, dann spart man da auch sehr viele Plattenzugriffe.

Nehmen wir folgendes Beispiel:

Code:

select * from a, b, c, d, e
where a.id   = b.id
and   b.xid  = c.id
and   c.yid  = d.id
and   d.zid  = e.id
and   a.wert = 4

Hier geht die Datenbank her und baut alle Daten über die ID's zusammen und schränkt dann die Ergebnismenge dahingehend ein, dass nur die Sätze übrig bleiben, bei der in a der Wert = 4 ist.

Wenn man das Statement nun so umstellt:

Code:

select * from b, c, d, e, 
(select id from a where wert = 4) x
where x.id   = b.id
and   b.xid  = c.id
and   c.yid  = d.id
and   d.zid  = e.id

so kann die Datenbank zuerst die Teilmenge bilden, die die Einschränkung enthält und muss dann aus den anderen Tabellen nur noch die Datensätze zur Ergebnismenge zusammenstellen, die zur einschränkenden Teilmenge gehören.
Und ist das eine Einschränkung auf vielleicht mal 10% oder gar weniger, so kann man hier deutliche Laufzeitunterschiede ausmachen.

So erlebt bei einer Oracle-Datenbank mit insgesamt in dieser Konstellation ca. 300 Mio Datensätzen, resultierend aus der Tabellenverknüpfung ohne die Einschränkung auf Wert = 4. Natürlich waren die Bedingungen deutlich komplizierter, aber vom Prinzip her war es so. Und den * ersetze man bitte immer durch die benötigten Spalten, auch wenn man dann mal viel schreiben muss. Jede selektierte, aber nicht benötigte Spalte, belegt nur unnütz Speicher und/oder Plattenplatz.

Andere Datenbanken mögen sich da vollkommen anders verhalten, daher lässt sich "Das richtige Vorgehen" nicht generalisieren.

Zitat von p80286:

Wenn schon das Datendesign nicht stimmt, bist Du noch schlimmer dran. Stell Dir vor 10 Adressfelder (ADR1..ADR10) und da mußt Du Orte suchen.

und das dann auch noch mit like '%ORTSNAME%'. Hatten wir hier doch kürzlich noch irgendwo in 'nem Thread.

Zitat von p80286:

(Durch Augenschein in einem professionellen System bestätigt)

Aber das professionell ist hier doch hoffentlich ironisch gemeint. Es war doch wohl eher ein System, für das man bezahlen muss