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

[nahpets]

Zitat von Jumpy:

Zitat von Sir Rufo:

Und wenn die Views zu komplex werden und dadurch das Erstellen der View zu lange dauert, dann erstellt man eine Tabelle, die dann wie die View genutzt wird (rein lesend).

Wie machst du das dann in der Praxis? Wird diese Zusatztabelle gefüllt, wenn die eigentlichen Tabellen gefüllt werden? Mit triggern usw? Oder wird diese Tabelle alle Nase lang mal neu erstellt/aktualisiert?

Wir haben (wenn sowas tatsächlich erforderlich ist) dann entsprechende Prozesse, die zu definierten Zeitpunkten die vorhandene Tabelle wegwerfen und per

Code:

Create table as select * from a,b,c,d,e,... where a.id = b.id...

neu erstellen. Dahinter läuft dann ein entsprechendes Script für die Indexerstellung, Statistiken...
Ein Truncate Table mit anschließender Neubefüllung kann es natürlich auch tuen. Gerade bei sehr großen Datenmengen kann es aber deutlich schneller werden, wenn man eine "indexlose" Tabelle befüllt und die Indexerstellung erst nach der Befüllung vornimmt. Die Indexpflege beim Befüllen kann, je nach Datenmenge, auch schonmal (gefühlt) Wochen dauern.

Es kann aber auch passieren, dass von einem Programm die Tabelle geleert wird und dann vom Programm die "Basisdaten" in diese Tabelle geschrieben werden und nachfolgende Prozesse mit den "Basisdaten" dieser Tabelle (und ggfls. weiteren Tabellen) Berechnungen durchführen, um diese dann in weiteren Spalten der Tabellen abzulegen.
Weitere Prozesse können dann auf die hier abgelegten "Basisdaten" + "Zusatzdaten" zugreifen und ggfls. weiter Ergebnisse in weiteren Spalten ablegen.

In den Systemen, die ich habe kennenlernen dürfen, haben die kleineren Tabellen sowas um die 30 Mio. Sätze gehabt, die größeren um die 150 bis 200 Mio.

Aber die Regel, die einem klar sagt, wie man soetwas macht, gibt es eigentlich nicht. Es kommt doch sehr auf die Datenmenge, die "Eigenheiten" des genutzten Datenbanksystems und letztlich nicht unerheblich auf die Hardware an, auf der der "ganze Spaß" läuft.

Zitat von Aurelius:

Es ist natürlich richtig, dass man durch Normalisierung etc. Einbußen in der Performance bekommt. Allerdings nehme ich persönlich sowohl im Datenbankdesign als auch im Quelltext Peformanceverluste (sofern sie im Rahmen bleiben und es keine zeitkritische Anwendung ist) in Kauf, solange dadurch das System verständlich und leicht wartbar/erweiterbar bleibt.

Dies halte ich für eine wesentliche Aussage. Mir ist noch kein System "in Finger" gekommen, an dem Anwender im Dialog "live" gearbeitet haben und bei dem aus Performancegründen eine Denormalisierung erforderlich war. An eine gezielte Denormalisierung denke ich erst, wenn es darum geht, die Laufzeit von Wochen auf Tage zu reduzieren.
Auch wenn ich ggfls. auf denormalisierte Daten schneller zugreifen kann, als auf normalisierte Daten, so darf ich den (Zeit)Aufwand für die Denormalisierung und deren Konsistenzhaltung nicht vergessen.

Habe ich in einem System mit 40000, 50000 Kunden und den zugehörigen Nachschlagtabellen ein Performanceproblem, so habe ich sicherlich ein Problem, dass nicht durch Denormalisierung sinnvoll gelöst wird, sondern eventuell nur eine schlecht konfigurierte Datenbank oder eine umständliche und resourcenfressende Umsetzung der Geschäftslogik.

Viele Performanceprobleme, die ich habe lösen müssen, lagen weder an der Normalisierung der Daten, noch an der Hardware, sondern einfach nur an äußerst umständlicher Umsetzung von Abfragen.

[Dejan Vu]

Zitat von nahpets:

Mir ist noch kein System "in Finger" gekommen, an dem Anwender im Dialog "live" gearbeitet haben und bei dem aus Performancegründen eine Denormalisierung erforderlich war.

Ich habe mal blöderweise ein EAV-Antipattern eingesetzt (ich dachte damals, ich wäre der Größte ). Alles perfekt: 5 Tabellen, um alles darstellen zu können. Nur: Die Antwortzeiten waren nicht hinnehmbar. Ich habe eine weitere Anwendung mit wenigen Mio Datensätzen, welches beim 10.Join in die Knie geht.

Das ist aber -muss ich zugeben- schon eine Weile her. Heute packt man einfach ein paar GB mehr RAM in den Server und dann läuft der. Außerdem lässt sich durch gutes DB-Design (Partitioning) sehr viel erreichen.

Trotzdem bin ich bei Produktionsdaten und der 3NF mittlerweile eher pragmatisch und verstecke mein Design hinter virtuellen Tabellen und/oder SP. So kann ich mein echtes DB-Design anpassen, wie ich lustig bin.

[nahpets]

@Dejan Vu
Klingt sehr vernünftig. "Das" richtige Vorgehen gibt es nicht, die Theorie mag noch so perfekt sein, wenn die Realität das nicht mit vertretbarem Aufwand abwickeln kann, muss eine pragmatische Lösung für den Einzelfall her.

Wer lange genug in dem Umfeld arbeitet, hat irgendwann seinen Erfahrungsschatz oder kennt jemanden mit dem Erfahrungsschatz für Problem X, jemanden für Problem Y... und dann wird (unter Zuhilfenahme von Creativität und einer gewissen Verspieltheit) die bestmögliche (umsetzbare und bezahlbare) Lösung gesucht.

Habe mal ein System neubauen müssen, dass vorher mit ausgereifter Software von der Analyse bis zur Implementierung (die von den Werkzeugen generiert wurde - sowohl Datenbank, als auch Programm), nach allen Regeln der Kunst erstellt wurde.
Das war seinerzeit die "Innovation" (seit dem hasse ich dieses Wort).
Preformance für die Tonne und als die "bekloppten Anwender" ein Feature haben wollten, dass diese Systeme nicht abbilden konnten, war es nicht möglich, die passenden Änderungen in den generierten Quelltext einzubauen.

Also Delphi genommen, Erfahrungsschatz dazu und vier Wochen fast ununterbrochen gearbeitet. Und dann war das fertig, pfleg- und wartbar und sauschnell.

PS.:
Schlecht implementierte Abfragen werden durch viel RAM nicht besser, sondern man verdrängt das Problem, bis das Mehr an Speicher irgendwann auch nicht mehr ausreicht (und der Zeitpunkt kommt immer, meist dann, wenn man nicht damit rechnet oder es extrem ungünstig ist - halt Murphy).

Unser o. g. Performanceprobleme hatten wir auf einem Datenbankhobel mit "nur" 64 CPUs und ich weiß nicht mehr 256 oder 512 GB Speicher. Ist fast ein Jahrzehnt her...

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

[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

[p80286]

Zitat von nahpets:

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.

Eine Alternative wäre auch

Code:

select * 
from a join b on (a.xid=b.id and a.wert=4)
       join c on (b.xid=c.id)
       join d on (c.yid=d.id)
       join e on (d.zid=e.id)

(ist allerdings von der DB abhängig)

Zitat von nahpets:

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

Ich werd' der Selbsteinschätzung des Herstellers doch nicht widersprechen

Gruß
K-H

[jobo]

Zitat von nahpets:

Nehmen wir folgendes Beispiel...

Die Überlegungen, die hier angestellt werden, würde ich heutzutage eher im Bereich Legendenbildung ansiedeln.
Konkret stammt das beschriebene Verhalten vielleicht von einer Oracle DB 7, 8, max 9 mit RBO oder einem neueren System, das per Schalter abwärtskompatibel eingestellt ist.

Generell sollte heute jedes System, das Statistiken beherrscht, eine solche Aufgabe sinnvoll lösen. Und zwar nicht mittels Mutmaßung, es könnte sich um 10% Einschränkung handeln. Auch wenn eine Bedingung "id=4" sehr selektiv aussieht- man könnte ja sogar fast denken, es sei ein Primärschlüssel mit Top Einschränkung =100%- es kann genausogut eine vollkommen wirkungslose Einschränkung sein, weil einer der anderen Joins ggF. gegen einen einzigen Datensatz läuft und id=4 für den gesamten Rest gilt.
Die Systemstatistiken sollten da helfen.

Also auch wenn es das alles mal gab und in entsprechend alten Systemen immernoch gibt. Aktuell sollte man bei der Formulierung von SQL Statements durchaus unbefangen vorgehen, zumindest bevor man Annahmen trifft, die nicht (mehr) stimmen.
Ausnahme wäre, man arbeitet gezielt an einem alten Oracle 7 oder 8. Dann besser die 20(oder 15?) Regeln des RBO durchlesen und befolgen. Bei anderen Systemen entsprechend.

Am Ende bleiben dann vielleicht ein paar Prozent problematischer Abfragenfälle, die etwas Forschung benötigen, einen gezielten Optimzer Hint oder vielleicht sogar eine Denormalisierung des DM.

[nahpets]

Zitat von jobo:

Zitat von nahpets:

Nehmen wir folgendes Beispiel...

Die Überlegungen, die hier angestellt werden, würde ich heutzutage eher im Bereich Legendenbildung ansiedeln.
Konkret stammt das beschriebene Verhalten vielleicht von einer Oracle DB 7, 8, max 9 mit RBO oder einem neueren System, das per Schalter abwärtskompatibel eingestellt ist.

Stimmt, ist fast ein Jahrzehnt her und war Oracle 8.

Grundsätzlich gehe ich immer her und schaue zuerst, wie bekomme ich mit einem lesbaren Statement mein Ergebnis, auf Performance... wird erstmal nicht geachtet, sondern auf eine möglichst einfache und korrekte Abbildung der fachlichen Anforderung. Das hat Priorität. Rumexperimentiert wird erst dann, wenn aktuelle Statistiken... nicht mehr helfen und man einen anderen Weg suchen muss, weil der einfachste Weg nicht auf vertretbare Weise zum Ziel führt. Klimmzüge erst dann, wenn es anders nicht geht.

Zitat von jobo:

Generell sollte heute jedes System, das Statistiken beherrscht, eine solche Aufgabe sinnvoll lösen. Und zwar nicht mittels Mutmaßung, es könnte sich um 10% Einschränkung handeln. Auch wenn eine Bedingung "id=4" sehr selektiv aussieht- man könnte ja sogar fast denken, es sei ein Primärschlüssel mit Top Einschränkung =100%- es kann genausogut eine vollkommen wirkungslose Einschränkung sein, weil einer der anderen Joins ggF. gegen einen einzigen Datensatz läuft und id=4 für den gesamten Rest gilt.

id=4 hat ja erstmal überhaupt keine Aussage, id könnte ja auch immer 4 sein, also ein über die gesamte Tabelle geltender, konstanter Wert. Dann hilft das hier natürlich nichts. Die Einschränkung mit id=4 war hier nur beispielhaft gemeint, in der konkreten Situtation wurde die Tabelle mit dem kleinsten Volumen auf ca. 3% der enthaltenen Datenmenge eingeschränkt, mit dem Resultat, dass in dem konkreten Fall auch die übrigen Tabellen auf eine ähnliche Teilmenge eingeschränkt werden konnten. Der Optimiser hat das da halt beim ursprünglichen Statement irgendwie nicht hinbekommen. (Egal, ist Schnee von vorgestern.)

Zitat von jobo:

Die Systemstatistiken sollten da helfen.

Also auch wenn es das alles mal gab und in entsprechend alten Systemen immernoch gibt. Aktuell sollte man bei der Formulierung von SQL Statements durchaus unbefangen vorgehen, zumindest bevor man Annahmen trifft, die nicht (mehr) stimmen.
Ausnahme wäre, man arbeitet gezielt an einem alten Oracle 7 oder 8. Dann besser die 20(oder 15?) Regeln des RBO durchlesen und befolgen. Bei anderen Systemen entsprechend.

Am Ende bleiben dann vielleicht ein paar Prozent problematischer Abfragenfälle, die etwas Forschung benötigen, einen gezielten Optimzer Hint oder vielleicht sogar eine Denormalisierung des DM.

Prinzipiell beschreibst Du das Vorgehen, wie ich es auch immer gehandhabt habe.
Probleme werden erst (und nur dann) gelöst, wenn sie auftreten. Ein voraussschauende Optimierung, mit Behebung von Problemen, deren Existenz nicht bewiesen ist, erfolgt selbstverständlich nicht.

[p80286]

Zitat von nahpets:

Schlecht implementierte Abfragen werden durch viel RAM nicht besser, sondern man verdrängt das Problem, bis das Mehr an Speicher irgendwann auch nicht mehr ausreicht (und der Zeitpunkt kommt immer, meist dann, wenn man nicht damit rechnet oder es extrem ungünstig ist - halt Murphy).

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.
(Durch Augenschein in einem professionellen System bestätigt)

Gruß
K-H