AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Zitat:
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. |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
@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... |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
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. |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Zitat:
(Durch Augenschein in einem professionellen System bestätigt) Gruß K-H |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Zitat:
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:
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.
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 Wenn man das Statement nun so umstellt:
Code:
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.
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 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:
Zitat:
|
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Zitat:
Code:
(ist allerdings von der DB abhängig)
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) Zitat:
Gruß K-H |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Zitat:
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. |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Zitat:
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:
Zitat:
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. |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Könnte wirklich sein, das das olle Kamellen sind.
Meine Probleme mit den DB sind auch ca. 10 Jahre alt. Mittlerweile überlasse ich das unseren DB-Spezialisten. |
AW: Steuerinformationen zu Datensatz in der selben Tabelle oder über 1:n-Relation
Hallo,
ich möchte hier mal George Orwell (bzw. Benjamin aus Farm der Tiere) zitieren: "Gott habe ihm zwar einen Schwanz geschenkt, um damit die Fliegen zu verscheuchen, doch er persönlich würde lieber sowohl auf Schwanz wie Fliegen verzichtet haben." mfg |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:16 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz