Geschwindigkeit von Views verbessern

[alzaimar]

Wenn in der View viele self joins vorhanden sind, oder allgemein sehr viele Tabellen verknüpft werden, versagt so ziemlich jeder Query-Optimizer. Selbst wenn Du jetzt dieses Problem durch Speichereinstellungen gelöst hast, wirst du später irgendwann an die Grenzen stoßen, die sich dann nicht mehr erweitertn lassen.

Neben Stored Procedures bieten sich auch Functions an. Rein konzeptionell würde ich Funktionen vorziehen, denn eine Funktion liefert ja etwas (z.B. eine Tabelle), während eine Prozedur etwas auslöst bzw. bewirkt.

Der prinzipielle Aufbau wäre dann:
1. Definiere Resultattabelle
2. Befülle die Tabelle mit dem PK sowie dem ersten Teil an Daten (z.b. max 8x JOIN, muss man ausprobieren)
3. Befülle die Tabelle mit dem nächsten Block
4. Usw
N. Liefere die Daten

[hoika]

Hallo,

was ihr alle gegen Views habt ???

Hier mein Senf. *gr*

SELECT d.* FROM datentabelle d, zugrifftabelle z WHERE d.mandant = z.mandant

sollte auf jeden Fall umgeschrieben werden.

SELECT d.* FROM datentabelle d
INNER JOIN zugrifftabelle z on d.mandant = z.mandant

Auf datentabelle.mandant und zugrifftabelle.mandant müssen Indizes liegen.
Die Indizes müssen "aktuell" sein (ausbalanciert)
Unter Firebird geht das mit Alter Index Inactive / Alter Index Active
unter PostgreSQL ???

#Update#, ANALYZE heisst das wohl.

Das ich als Client nicht mit Select * From View
auf den View gehe und dann alle Daten am Stück laden,
ist genauso klar wie es bei Tabellen ist.

Warum der Query-Optimizer bei der Verwendung von Views Probleme bekommen soll,
ist mir nicht ganz klar, es sei denn du meinst Views mit vielen Joins.
Wenn ein User solche Views auch noch verjoint, gibt das natürlich etwas Arbeit
für den Optimizer.



Hier noch ein paar interessante Links.
Du solltest dir mal besionders Partitionierung ansehen.

PostgreSQL optimieren

Materialized View


Heiko

PS: An dem OpenSource-Tag war ich dabei

[mkinzler]

Das ändert aber nichts daran, dass alle Rechte aller Benutzer abgefragt werden, obwohl er nur die Rechte eines Benutzer benötigt

[hoika]

Hallo,

nun der View sollte natürlich auch anständig,
also effektiv, definiert sein.


Heiko

[Errraddicator]

Zitat von mkinzler:

Das ändert aber nichts daran, dass alle Rechte aller Benutzer abgefragt werden, obwohl er nur die Rechte eines Benutzer benötigt

Nein das ist nicht richtig, denn mein Beispiel von oben war ja ein stark vereinfachter Aufbau.
Wenn ich meine komplette Struktuer hier aufzeichne, habe ich gleich doppelt so viele Tabellen.

Echte Tabellen
benutzertabelle
mandantentabelle
zugriffstabelle
datentabelle

Views:
benutzer_effektiv
mandanten_effektiv
zugriff_effektiv
daten_effektiv

...

Ich habe also für jede Tabelle (egal ob Mandant, Daten, Benutzer, Zugriff oder sonst was) eine View auf der ich jeweils nur die Daten sehe die mich betreffe und nur darauf bastelt der User rum.

Und bei den tiefer gehenden Views baue ich logischerweise schon auf den vorherigen Views auf.
Also heißt es konkret nicht
"Select d.* from datentabelle d, zugriffstabelle z WHERE d.mandant = z.mandant" sondern
"Select d.* from datentabelle d, zugriff_effektiv z WHERE d.mandant = z.mandant" Das war ja nur ne vereinfachte Darstellung.

...

Und zu der ständigen Aussage "Weg von Client/Server Technolige, wir ham 2009 nich 1990, mach dies, tu das".
Wie soll ich das denn bei einer PHP-Anwendung machen?

Das ist doch prinzipbedingt eine C/S Anwendung, oder sehe ich das falsch?

[mkinzler]

Deine Abfrage ist trotzdem ein Inner Join über die beiden Tabellen, also alle Rechte aller Benutzer!

[alzaimar]

Zitat von hoika:

was ihr alle gegen Views habt ???

Die RDBMS-Engine ist dahingehend optimiert, das sie einen Index komplett im Speicher hält. So ein Index kann aber ganz hübsch groß werden. Wenn man un eine Query mit vielen Joins hat, dann ist der Speicher manchmal einfach voll und Windows muss swappen. Was eben noch eine Query-Optimierung war (Index komplett im RAM halten), wird jetzt zum Pferdefuss (Windows paging).

Wenn ich nun die Generierung der Resulttabelle aufteile, dann klappt es mit dem RAM wieder und ich bekomme 1-fix-3 mein Ergebnis.

Ich finds auch blöd, solche Workarounds zu basteln, aber leider kommt man manchmal nicht drumherum.

[p80286]

Zitat von alzaimar:

.... dann ist der Speicher manchmal einfach voll und Windows muss swappen.

jetzt weiß ich auch warum sich MS-SQL mit einem Timeout verabschiedet und Oracle alles ruckzuck liefert.
Oracle lauft unter ..ix

Gruß
K-H

[hoika]

Hallo,

bei MS-SQL muss man den maximalen Speicher
manuell festlegen, sonst verbrät der alles.


Heiko

[Elvis]

Zitat von Errraddicator:

Und zu der ständigen Aussage "Weg von Client/Server Technolige, wir ham 2009 nich 1990, mach dies, tu das".
Wie soll ich das denn bei einer PHP-Anwendung machen?

Sogar PHP wird Remoting-Möglichkeiten wie SOAP kennen. Falls du überhaupt einen Rich/Smart Client haben willst. Sieht mir eher nach einer Website aus.

Zitat:

Das ist doch prinzipbedingt eine C/S Anwendung, oder sehe ich das falsch?

Nö, nicht in dem Sinne, den ich meinte.
Ich bezog mich bei C/S darauf, dass dabei der User direkten Zugriff auf die DB hat, und man deshalb so abartige Vergewaltigungen von RDMS-Features und Serverhardware braucht, um sich gegen diese Zugriffe des Users abzusichern.
Deine PHP Page wird ja selbst Zugangskontrolle ausüben, also warum denn das ganze NOCHMAL innerhalb der DB machen?
Will heißen, du sorgst doch in dem PHP-Server schon dass User X nur Dinge sehen/machen darf, die er auch wirklich sehen/machen darf.
Warum willst du denn jetzt zusätzlich eine weitere Kontrolle einbauen, die dich dann immer und überall CPU-Zyklen, Speicher und vernünftige Querypläne kostet?