Re: Frage zu View-Tabellen

Christoph Ingenhaag schrieb:

"Elmar Boye" wrote:

Hallo Hilmar,

Hilmar Bunjes schrieb:
ich arbeite derzeit an einem Reservierungssystem und benötige gerade eine Funktionalität, um eine Anzahl freier Plätze zu bestimmten Zeiträumen zu bekommen. Da ich aufgrund von Einschränkungen bei meinem OR-Mapper keine Stored Procedures verwenden kann, überlege ich, eine ähnliche Funktionalität über View-Tabellen zu bekommen.
Ich bin mir aber unsicher, wie View-Tabellen intern gehandhabt werden.
View-Tabellen gibt es nicht, eine Sicht (View) ist ein
eigenes Element in SQL.

Sichten (View) sind in ihrer Grundform gespeicherte Abfragen,
die vom SQL Server beim Ausführen kompiliert und ausgeführt
werden. Sie benötigen keinen zusätzlichen Speicherplatz,
abseits ihrer Definition:
<URL:http://msdn2.microsoft.com/de-de/library/ms190174.aspx>

Erweiterungen sind indizierte Sichten (SQL Server 2000), die
zusätzliche Daten für den Zugriff speichern:
<URL:http://msdn2.microsoft.com/en-us/library/aa933148(SQL.80).aspx>
Bzw. ab SQL Server 2005 partitionierte Tabellen und Indizes:
<URL:http://msdn2.microsoft.com/de-de/library/ms188706.aspx>

und etwas weniger abstrakt der Artikel:
<URL:http://msdn2.microsoft.com/en-us/library/ms345146.aspx>

Beide sind transparent für die Anwendung und unabhängig
vom Einsatzbereich (Abfrage, Prozedur, Funktion, Sicht).
Sie könnten für den von Dir beschriebenen Anwendungsbereich
von Nutzen sein, wenn Du mit grösseren Volumina umgehst.

Kann ich mir vorstellen, dass diese ähnlich wie Stored Procedures
> nur auf die Daten zugreifen, die ich gerade anfrage?

Ja.

Wäre es also von der Performance und vom Speicherverbrauch ein Unterschied, ob ich eine Anfrage auf eine View-Tabelle oder eine Stored Procedure schicke?
Nein.


Doch.
Wärend eine View eine virtuelle Tabelle ist, deren Definition (also das SQL Statement) geparsed und als sog. algebrizer tree im Cache abgelegt wird bzw. bei indizierten views der Inhalt materialisiert wird (also tatsächlich gespeichert wird und nicht mehr virtuell ist) [Partitionierung mal ausser Acht gelassen], ist eine Stored Procedure etwas ganz anderes. Bei Stored Procedures wird der kompilierte Ausführungsplan im Cache gespeichert, der bei Zugriffen auf die View in der Regel neu erstellt wird. Gleiches Verhalten erreicht man auch, wenn man prepared statements statt adhoc statements verwendet.
Bei simplen Statements ist der SQL Server in der Lage die hierfür erzeugten Ausführungspläne für bis auf die Parameter verschiedene AdHoc statements weiderzuverwenden.

Die vielen Worte ändern nichts daran, daß es Spitzfindigkeiten sind.
Auch für eine Abfrage, die auf einer Sicht basiert, erstellt der
SQL Server einen Abfrageplan (zusammen mit den Parametern) und
cacht diesen. Und das Verhalten ist somit vergleichbar mit einer
Prozedur, die eine Abfrage enthält.
Größere Unterschiede gibt es bei neueren SQL Server Versionen
an der Stelle nicht mehr.

Der Performance Unterschied kann also darin bestehen, das der Aufwand zur Kompilierung entfällt und der Unterschied im Speicherverbrauch besteht darin, das nur wenige kompilierte Pläne im Cache vorhanden sind und der Cache für andere Dinge verwendet werden kann.

Und genauso kann anderes rum ein Schuh daraus werden.
Eine Prozedur kann bei ungünstigen Parametern beim Erstaufruf einen
"schlechten" Abfrageplan haben, der dann weiterverwendet wird.

Für die eigentliche Fragestellung IMHO hilft das nicht weiter -
deswegen erspare ich mir weitere Diskussion bezüglich Plan Guides etc.

Gruß Elmar



.

Relevant Pages

  • Re: Frage zu View-Tabellen
    ... eigenes Element in SQL. ... wenn man prepared statements statt adhoc statements ... Kompilierung entfällt und der Unterschied im Speicherverbrauch besteht darin, ... der Vorteil von Stored Procedures gegenüber prepared statements liegt ...
    (microsoft.public.de.sqlserver)
  • Re: basic question
    ... Currently we have are doing calculations via stored procedures ... in which case *I* would like to have them run on the SQL server ... procs are doing. ...
    (microsoft.public.dotnet.general)
  • Re: Stored Procedure vs direct execute SQL
    ... another of dynamic sql (otherwise SQL Server can't take advantage of ... You seem to be saying that SQL Server can use ... To say that stored procedures are "far ... > select listingId, listingName from Property ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: DB Architecture Questions (for joe celko)
    ... much more flexibility and scalability. ... Although in the reality I live in, stored procedures ... SQL Server, this means that you will have a lot of round trips for data ...
    (microsoft.public.sqlserver.programming)
  • Re: Insert Date and Time in SQL Server 2000 using ASP
    ... > applications that actively communicate with SQL Server, ... Oracle any more than necessary") but we have a single application that works ... The effort to code the SQL logic into 3 separate sets of stored procedures ...
    (microsoft.public.inetserver.asp.general)
Quantcast