Vor- und Nachteile von Views

[bigpoint]

Das der Execution Plan bei Views oder nacktem SQL jedesmal neu erstellt wird stimmt nicht.

Woher hast du die Informationen ??

Denn es stimmt nicht

Bei SP und Funktionen wird der Ausführung Plan nur einmal erstellt, und zwar bei anlegen oder ändern.

Der wird gecached und bei identischen Abfragen erneut verwendet. Genau wie im Fall einer SP.

Genau ist es.

Leider aber für SQL gilt es solange die Transaktion offen ist und bei SP solange man die nicht aktualisiert.

Kannst du deine Aussage, dass Prozeduren generell schneller sind, als Views (und sei es nur bei einem besimmten RDBMS) sinnvoll belegen?

Des weitere werden Funktionen und SP kompiliert und auf dem Server als Objekte angelegt.

Das ist noch ein weiterer Grund warum SP schneller als nacktes SQL ist.

[Jasper]

Woher hast du die Informationen ??

Denn es stimmt nicht

Bei SP und Funktionen wird der Ausführung Plan nur einmal erstellt, und zwar bei anlegen oder ändern.

hör bitte auf unsinn zu posten. nachtgeist hat vollkommen recht, der ausführungsplan wird für jedes statement erstellt, gespeichert und bei nochmaliger verwendung des identischen statements wiederverwendet.

kann man sich über v$sqlarea ansehen. die informationen stehen u.a. in der oracle doku im concepts guide, kapitel 24.

Das ist noch ein weiterer Grund warum SP schneller als nacktes SQL ist.

und wenn wir schon bei kapitel 24 sind: daran wird auch erklärt, dass PL/SQL eine ERWEITERUNG von sql ist, d.h. die PL/SQL-engine erstellt statements für die sql-engine. sql-statements werden dagegen DIREKT von der sql-engine verarbeitet. kannst du mir mal erklären, wie PL/SQL da schneller als SQL sein soll?

-j

[bigpoint]

Also ich sehe ich habe einen Oracle Spezialist vor mir

Gut über Oracle und seine Abläufe will ich nicht diskutieren da ich über Oracle zu wenig Ahnung habe. Ist aber bei SQL Server 100% so und wenn es bei Oracle nicht so ist, dann ist es bestimmt ein großer Nachteil gegenüber SQL Server.

Noch was zu Prozeduren, was denkst Du, warum heißen sie Gespeicherte Prozeduren??

Sicherlich bei kleinen abfragen wird sich der unterschied zwischen SP und TSQL nicht auswirken, aber bei komplexen Abfragen jedoch bestimmt.

Und jeder der über Prozedurcache schon was gehört hat weiß worüber ich rede.

[kills]

Noch was zu Prozeduren, was denkst Du, warum heißen sie Gespeicherte Prozeduren??

Ich denke das Prozeduren "Prozeduren" heissen, weil Sie mehr sind als ein einfaches SQL Statement.

z.b. hab ich die möglichkeit for-Schleifen zu verwenden usw.

Sie sind einfach ein ablauf mehrere SQL-Statements die auch mit If-Cases o.ä. verzweigt sein können.

Wie du aus dem Wort "Prozeduren" auch "mehr performance" oder "schneller" lesen kann, ist für mich unverständlich.

[bigpoint]

Wie du aus dem Wort "Prozeduren" auch "mehr performance" oder "schneller" lesen kann, ist für mich unverständlich.

Vielleicht macht diesen Artikel die Sache ein wenig klar

[Nachtgeist]

Ist aber bei SQL Server 100% so

http://www.databasejournal.com/features/mssql/article.php/3067071

Because the stored procedure execution plan can be outdated, for example when large amounts of data modifications are made to a table referenced by a stored procedure, you may need to recompile the execution plan. SQL Server 2000 automatically recompiles the stored procedure execution plan when one of the following conditions are met:

[...]

Ausserdem lesenswert: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_sa_4azp.asp

und:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_da_0nxv.asp

SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans.

und wenn es bei Oracle nicht so ist, dann ist es bestimmt ein großer Nachteil gegenüber SQL Server.

Jedes moderne RDBMS handhabt das so.

Noch was zu Prozeduren, was denkst Du, warum heißen sie Gespeicherte Prozeduren??

Weil sie in Form einer Funktion (Prozedur) auf dem Server abgelegt (Stored) werden.

[Jasper]

Gut über Oracle und seine Abläufe will ich nicht diskutieren da ich über Oracle zu wenig Ahnung habe. Ist aber bei SQL Server 100% so und wenn es bei Oracle nicht so ist, dann ist es bestimmt ein großer Nachteil gegenüber SQL Server.

dann frage ich mich, warum du trotz nachfrage behauptet hast, jedes funktionen und prozeduren unterstützende dbms würde sich so verhalten.

zu ms-sql sag ich nichts, ist nicht mein gebiet. wenn ms-sql allerdings jedes statement neu parsen sollte verschenkt das dbms massiv performance (sehe ich nicht unbedingt als vorteil) und das kann ich mir ehrlich gesagt nicht so recht vorstellen. aber ist wie gesagt (gottseidank) nicht mein gebiet.

-j

[bigpoint]

dann frage ich mich, warum du trotz nachfrage behauptet hast, jedes funktionen und prozeduren unterstützende dbms würde sich so verhalten.

Weil ich kann mir nicht vorstellen, dass zB. Oracle jedes mal bei ausführen

von SP oder Funktionen der Ausführung Plan neu erstellt und kompiliert.

Was sind dann die Vorteile \ unterschiede von SP und Funktionen bei Oracle ?

zu ms-sql sag ich nichts, ist nicht mein gebiet. wenn ms-sql allerdings jedes statement neu parsen sollte verschenkt das dbms massiv performance (sehe ich nicht unbedingt als vorteil) und das kann ich mir ehrlich gesagt nicht so recht vorstellen. aber ist wie gesagt (gottseidank) nicht mein gebiet.

-j

Stell Dir vor folgendes, man hat bei Oracle am einem Tag 1000 unterschiedliche sql statemens zu ausführen, pro statement eine Transaktion. An einem anderem Tag wieder 1000 andere statemens und so weiter. Wo wird es gespeichert und wo zu ???

Ist da irgend wann nicht der Speicher platz knapp ??

[Nachtgeist]

Weil ich kann mir nicht vorstellen, dass zB. Oracle jedes mal bei ausführen von SP oder Funktionen der Ausführung Plan neu erstellt und kompiliert.

Tut es auch nicht. Die Plans werden schliesslich gecached.

Stell Dir vor folgendes, man hat bei Oracle am einem Tag 1000 unterschiedliche sql statemens zu ausführen, pro statement eine Transaktion. An einem anderem Tag wieder 1000 andere statemens und so weiter. Wo wird es gespeichert und wo zu ???

Die Plans im Cache werden - je nach DBMS und Konfiguration - aus dem Cache entfernt, wenn sie zu alt sind. Wenn ein Plan laenger nicht gebraucht wird ('aging'), wird er also entfernt.

Das DBMS kann erstmal nicht wissen, ob das selbe Statement nochmal abgesett wird oder nicht. Wenn du aber genau so eine Anwendung hast, kannst du dein RDBMS in der Regel entsprechend tunen.

Eine der Seiten, die ich oeben gepostet habe, beschreibt das Aging fuer den MS SQL-Server ganz gut.

Ist da irgend wann nicht der Speicher platz knapp ??

Spaetestens dann fliegen alte Execution Plans aus dem Speicher ...

[Jasper]

Stell Dir vor folgendes, man hat bei Oracle am einem Tag 1000 unterschiedliche sql statemens zu ausführen, pro statement eine Transaktion. An einem anderem Tag wieder 1000 andere statemens und so weiter. Wo wird es gespeichert und wo zu ???

Ist da irgend wann nicht der Speicher platz knapp ??

als ergänzung zu nachtgeists post:

ein hard parse (also vollständiges parsen eines statements) ist extrem teuer, stellenweise dauert er länger als die nachfolgende ausführungsphase. warum soll man ein statement wieder und wieder komplett parsen wenn man es bereits schon einmal erledigt hat und man daher weiss, dass das statement syntaktisch richtig ist und wie man es am besten ausführt? den aufwand kann man sich sparen.

und so viele unterschiedliche statements hat eine anwendung gar nicht.

oftmals ändern sich nur die werte, nicht die statements an sich (ansonsten sollte man das design der anwendung nochmal gründlich überdenken). durch die verwendung von bind parametern kann man so ein statement immer wieder verwenden ohne es jedesmal komplett parsen zu müssen. und das bringt performance.

-j