Announcement

**Andreas Horlaender** · 09.12.2002, 23:49

Hallo Carsten,
Wenn die Daten ohne Einschr�nkungen ge�ffnet werden kommt es fr�her oder sp�ter immer zu Zeitlichen Problemen, daf�r gibt es ja WHERE.
Im Client Server ist die Mengenorientierung entscheidend (kleine Menge = schnell; gro�e Menge = langsam);
Normalisierung hat vor und Nachteile das muss immer im jeweiligen Fall beurteilt werden. 
Beispiel:
<li>Eine Tabelle verwaltet Artikel und Artikelgruppen das w�rde ich in jedem Fall Normalisieren</li>
<li>Diese Tabelle hat ein Boolesches Feld (Y/N) Char(1) das w�rde ich nicht Normalisieren.</li>
Gru� Andrea

**Carsten Haberland** · 10.12.2002, 11:00

Danke Andreas! 
Ich glaube, da sind wir uns einig, dass eine Normalisierung Vor- und Nachteile hat. Wir haben sie jedoch nicht soweit getrieben, dass wir beispielsweise bool. Felder normalisieren. Hier setzen wir Domains ein. 
Nur leider sind unsere Ladezeiten bei grossen Datenmengen nicht akzeptabel. Gibt es vielleicht noch andere Tricks bei Interbase, die Geschwindigkeit zu erh�hen? 
Beispielsweise haben wir die Buffergr�sse auf 10000 hochgesetzt, aber irgendwie hat das alles noch langsamer gemacht! 
MfG, Carsten <br&gt

**G�nter Forster** · 10.12.2002, 11:27

Hallo Carsten,

werden den von allen Tabellen mehrere Datens�tze gleichzeitig genutzt ?
Ansonsten ist eine Aufteilung sinnvoll, wenn eine Abfrage nur Einzelinformationen liefert werden die Daten per Stored Procedure abgeholt, die Tabellarischen Daten per Select.

Ich habe einige Projekte, die pro Auftrag / Bestellung 10 - 15 Tabellen abfragen, durch die Aufteilung hat sich die Performance verdoppelt,

Gru� G�nte

**Carsten Haberland** · 11.12.2002, 12:35

Hallo G�nter, 
danke erstmal f�r deine Antwort! 
Die Views sind so aufgebaut, dass sie Informationen zu allen Werkzeugen, die sich in der Datenbank befinden, aus unterschiedlichen Tabellen per join zusammenf�hren (wie Hersteller, Lagerort, Status, ...). Somit kann die Anwendung per select diverse �bersichten anbieten. 
Mit Aufteilung meinst du sicherlich die Normalisierung der Daten in verschiedenen Tabellen?! 
Wir haben jetzt �ber mehrere Testl�ufe herausgefunden, dass zugeh�rige Blobfelder zu einem Datensatz in separaten Tabellen ausgelagert werden und innerhalb der View nur eine ID auf diese verweisen sollte. Je nachdem wie die Views aufgebaut sind, haben wir eine Performance-Verbesserung bis zu 50% erhalten! 
MfG, 
Carsten<br&gt

**G�nter Forster** · 11.12.2002, 12:51

Hallo Carsten,

wenn Du alle Daten per join vor dem Select verkn�pfst hast Du ja, wie dur beschrieben hast, sehr gro�e Views.

Ist das in der Anwendung n�tig ? Beispiel :
Ich habe eine Produktdatenbank mit 5 Tabellen, in denen jeweils nur eine Tabellenzeile auf das Produkt zutrifft sowie 4 Tabellen, in denen mehrere Zeile Info und Blobs zu dem Produkt bestehen.

Der Anwender sieht ein 2 - geteiltes Fenster :
a.) Produktliste aus der Haupttabelle, nur 2 joins mit Hersteller und Ger�teart.
b. ) Alle Unterinformationen aus den anderen Tabellen mit Stored - Procedures abgefragt, wenn Afterscroll ausgel�st wird.
Tempo ist vollkommend ausreichend bei z.zeit 2 Mio Datens�tzen und
100 Infofeldern.
Die verschiedenen Select werden dann an die Haupttabelle geschickt,
die Afterscroll - Routine kann man mit etwas Pflege anpassen.

Gru� G�nte

**Klemmo** · 11.12.2002, 16:33

ab ca 6-7 Tabellen in einem SQL (daher auch in Views) macht der InterBase Optimierer seinem Namen keine Ehre mehr und verkn�pft die Tabellen nicht unbedingt in der Reihenfolge, wie es m�glich w�re, d.h. obwohl Inidizes gesetzt sind, werden die ignoriert. Bei der Abfrage �ber eine Stored Procedure, die in For Select Schleifen die Daten zusammen sucht, kann man die Zugriffsreihenfolge selbst bestimmen. Auch wenn es im Moment so aussieht, das alles recht schnell ist, evtl. macht der Server jetzt schon f�r einen User alles dicht, wenn dann 10 oder 100 User zugreifen, geht manchmal nix mehr. Gruss Holger www.ibexpert.co

**Heiko Luettge** · 11.12.2002, 22:07

Hallo, 
Interbase soll ja Probleme mit joins > 7 oder 8 Tabellen haben, 
speziell die Optimierung hapert etwas (beim join wird nur bei der 1. tabelle ein index benutzt). 
ich w�rde erst mal pr�fen, wie der view optimiert wird (z.B. planalyzer oder ibconsole). 
beim erzeugen des views wird die interne abarbeitung festgelegt, wenn sich an den tabe�llen was �ndert (indizes), muss der view neu erzeugt werden.
 
 
heik

**Carsten Haberland** · 12.12.2002, 11:09

Danke nochmal an alle! 
G�nter: 
Klingt einleuchtend, was du da gemacht hast! Sind die 2 Mio. Datens�tze auf alle Tabellen verteilt oder allein in der Haupttabelle? Die 100 Infofelder sind dann sicherlich je Produkt auf die anderen verteilt!? 
Holger: 
Das wusste ich noch nicht, dass Interbase-Optimierer bei join-Views ab 7 Tabellen schlapp macht. Danke f�r den Hinweis, dann hab ich schon ein Punkt mehr, wo wir noch ansetzen k�nnen. 
Heiko: 
Auch das mit den Indizes war mir noch nicht richtig klar, wie Interbase das bei joins h�ndelt. Klar ist es logisch, dass man bei derartigen Views die wesentliche Tabelle als erste setzt und alle anderen per join bzw. left join anh�ngt. Wenn ich aber mehrere Indizes auf der Haupttabelle habe (1. primary key, 2. Namensfeld, ...), werden auch alle genutzt? 
Wir haben auch ein Update-Tool, welche sp�ter regelm�ssig bei Wartungen die meisten Views entfernt und wieder neu erzeugt! 
Noch eine Frage! 
Die Software wird in Delphi programmiert. Wir nutzen als Datenbank-Komponente SDEngine (SQLDirect). Ist hier vielleicht noch Optimierung m�glich? Hat jemand mit dieser Komponente schon Erfahrungen gemacht, was das �ffnen von grossen Views angeht? 
MfG, Carsten<br&gt

**G�nter Forster** · 12.12.2002, 22:41

Hallo Carsten,

Info : 1 HAupttabelle mit 200 000, Detail und Beschreibungstabellen je 200 000 bis 2.000.000, Nachschlagetabellen je 200 - 2000 Datens�tze. Insgesamt pro Zeile ca 50 Datens�tze der Tabellen, wobei die meisten mit Stored Procedures abgeholt werden.

Hinweis, seit die Datenbank auf Firebird 1.0 l�uft sind komplexe Abfrage z�giger in der Ausf�hrung. Eventuell greifen die Buffer - Einstellungen der Delphi-Komponenten und der Datenbank hier besser. (Es stand mal so etwas bei sourceforge.net). Ich nutze simpel die mitgelieferten IBX in der Version 5.04.

Gru� G�nte

**Michael Ebner** · 18.12.2002, 17:37

1.) Mit der Reihenfolge, in welcher die Tabelle aufgef�hrt werden, kann man die meisten JOINs noch ein wenig optimieren.

2.) Es macht durchaus einen Unterschied, welcher JOIN verwendet wird. Ich habe das mal durchgemessen anhand einer Verkn�pfung von drei Tabellen, bei denen alle vier m�glichen JOINs dieselbe Ergebnismenge gebracht haben.

Ausf�hrungszeiten (ohne Query-Plan)

INNER JOIN 20,8 ms
LEFT OUTER JOIN 5,6 ms
RIGHT OUTER JOIN 4000 ms
FULL OUTER JOIN 20000 ms

Die Verh�ltnisse m�gen sich von Situation zu Situation verschieben, es zeigt sich aber, dass zwischen verschiedenen Formulierungen, die alle dieselbe Ergebnismenge bringen, erhebliche Unterschiede in den Ausf�hrungszeiten bestehen k�nnen.

Also: Anweisung und deren Plan genau analysieren und dann viel experimentieren

Announcement

Arbeiten mit grossen Views

Arbeiten mit grossen Views

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment