Keinen View aus Performancegründen?

[BerndL]

Hallo,
Ich lerne jetzt schon das zweite Jahr SQL und jetzt gab es einen Lehrerwechsel bei uns.
Mein Lehrer verbietet uns jetzt Views zu verwenden da sie das Programm zu langsam machen würden.

Jetzt wollte ich gerne von euch wissen ob dies stimmt, denn unser alter Lehrer hatte nichts dagegen und ein View ist ja nur eine Art Zeiger auf bestimmte Teile der Tabelle und kopiert ja nichts und erzeugt dadurch auch keine Redundanz im Programm.

[dimitri]

Jetzt wollte ich gerne von euch wissen ob dies stimmt

Klares jein. Eine View kapselt ein SQL wie Du schon gesagt hast. Dabei ist auch versteckt, welches SQL genau dahinter steckt. Wenn man also einfach so eine View verwendet, kann es durchaus sein, dass im Hintergrund viel mehr passiert als man eigentlich braucht (evtl. benötigt man viel weniger Felder als die View bietet o.ä.).

Dies kann einen Aufruf durchaus langsamer machen als wie wenn man speziell für eine Anforderung ein eigenes SQL schreibt. bei dem man selbst steuert was passiert.

Grundsätzlich ist aber schon so, dass ein SQL innerhalb einer View nicht schneller ist als das 1:1 Pendent das man außerhalb einer View abschickt.

Ich persönlich schließ mich eurem Lehrer an, denn genau das was ich oben beschrieben habe ist auch bei uns passiert bzw. passiert noch.
Laßt die Hände von Views das wird in Datenbanken mit vielen Tabellen schnell unübersichtlich wenn man das nicht plant und diszipliniert handhabt.

Dim

PS: Mit einem Zeiger wie in C hat eine View absolut nichts zu tun.

[O. Helper]

Hallo BerndL & dimitri,

Grundsätzlich ist aber schon so, dass ein SQL innerhalb einer View nicht schneller ist als das 1:1 Pendent das man außerhalb einer View abschickt.

Also da möchte ich doch zumindest ein klein wenig heftig widersprechen.
Ein View ist schon mal kompiliert, ein Schritt und zugleich Aufwand der gegenüber einer Ad-Hoc Query weg fällt.
Was die Performanz betrifft, da ist immer die Qualität der Query der massgeblich Faktor. Ich kann Views gleichermassen gut oder schlecht schreiben wie AdHoc Queries.

Wo ich Dir, dimitri, Recht gebe, ist das der Vorteil zugleich einen Nachteil haben kann, der festgelegte Execution Plan kann je nach Parameter inoptimal sein.
Aber deswegen Views zu verdammen, also davon halte ich ja nun gar nichts. Das Konzept der Views gibt es in jeder mir bekannten DBMS und das nicht gerade grundlos.

Und Lehrer die per se verbieten gehören verboten; meine Meinung.

[dimitri]

Ein View ist schon mal kompiliert, ein Schritt und zugleich Aufwand der gegenüber einer Ad-Hoc Query weg fällt.

Der Ausführungsplan ist mitnichten festgelegt. Zumindest in oracle überhaupt nicht wie sollte das auch funktionieren?
Beispiel:

create table t as select * from all_objects;
create view t_view as select owner,object_id,object_type from t;

explain plan for select * from t_view;
PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                            
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
Plan hash value: 1601196873                                                                                                                                                                                                                                                                                  
                                                                                                                                                                                                                                                                                                             
--------------------------------------------------------------------------                                                                                                                                                                                                                                   
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |                                                                                                                                                                                                                                   
--------------------------------------------------------------------------                                                                                                                                                                                                                                   
|   0 | SELECT STATEMENT  |      | 60167 |  2409K|   282   (1)| 00:00:04 |                                                                                                                                                                                                                                   
|   1 |  TABLE ACCESS FULL| T    | 60167 |  2409K|   282   (1)| 00:00:04 |                                                                                                                                                                                                                                   
--------------------------------------------------------------------------                                                                                                                                                                                                                                   

PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                            
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
Plan hash value: 961378228                                                                                                                                                                                                                                                                                   


explain plan for select * from t_view order by owner;

select * from table(dbms_xplan.display);
                                                                                                                                                                                                                                                                                                             
-----------------------------------------------------------------------------------                                                                                                                                                                                                                          
| Id  | Operation          | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                                                                                                                                                                                                          
-----------------------------------------------------------------------------------                                                                                                                                                                                                                          
|   0 | SELECT STATEMENT   |      | 60167 |  2409K|       |   926   (1)| 00:00:12 |                                                                                                                                                                                                                          
|   1 |  SORT ORDER BY     |      | 60167 |  2409K|  3080K|   926   (1)| 00:00:12 |                                                                                                                                                                                                                          
|   2 |   TABLE ACCESS FULL| T    | 60167 |  2409K|       |   282   (1)| 00:00:04 |                                                                                                                                                                                                                          
-----------------------------------------------------------------------------------

Gleiche View - anderer Ausführungsplan. Oracle kann auch Statements in denen eine View verwendet wird so umbauen, dass das Statement mit dem übergeordneten Statement gemergt wird.
Der Ausführungsplan ist also alles andere als festgelegt. Des weiteren wird der Plan natürlich im Shared Pool abgelegt und ist damit wiederverwendbar - auch wenn die Session die den Hard Parse ausgelöst hat beendet wird.

Ein Plan kann auch wieder invalidiert werden, wenn sich z.B. die Statistiken der Tabellen unterhalb einer View ändern. Hier wird aber mitichten die View geändert.

Aber vielleicht ist das im SQL Server ja auch komplett anders?

der festgelegte Execution Plan kann je nach Parameter inoptimal sein.

Das meinte ich nicht. Nehmen wir mal an, jemand möchte aus einer View zwei Spalten selektieren, die View liefert aber 10 Spalten. Um diese Informationen bereitszustellen sind aber Joins über, sagen wir, 6 Tabellen notwendig. Für meine zwei benötigten Spalten würde in einem eigenen Statement aber ein join über nur zwei Tabellen reichen.

Da ich das evtl. nicht weiß (oder es mir egal ist) braucht meine Abfrage also mehr Ressourcen als bei einem eigenen SQL. Dies ist meiner Meinung nach eine der großen Gefahren von Views in umfangreichen Projekten.

Dim