Re: Frage zu View-Tabellen

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



"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.
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.
Ob das Auswirkung auf deine Applikation hat, hängt von verschiedenen
Faktoren ab. Ausschlaggebend ist hier insbesondere wie oft Statements
aufgerufen werden: Also Last. Entsprechende Lasttest deiner Applikation
verraten dir, wann dein SQL Server in die Knie geht.

btw, der Vorteil von Stored Procedures gegenüber prepared statements liegt
darin, dass man eine weitere Abstraktionsschicht gegenüber der Anwendung hat.
Änderungen, insbesondere solche aus Performancegesichtspunkten, lassen sich
hier mit viel weniger Aufwand umsetzen als Änderungen in der Applikation.

Vg
Christoph


.

Relevant Pages

  • Re: Frage zu View-Tabellen
    ... eigenes Element in SQL. ... Erweiterungen sind indizierte Sichten (SQL Server 2000), ... Performance und vom Speicherverbrauch ein Unterschied, ob ich eine Anfrage auf eine View-Tabelle oder eine Stored Procedure schicke? ... Bei Stored Procedures wird der kompilierte Ausführungsplan im Cache gespeichert, der bei Zugriffen auf die View in der Regel neu erstellt wird. ...
    (microsoft.public.de.sqlserver)
  • How do I do Paging through a large dataset via Stored Procedures
    ... Paging by dynamically altering the SQL Query ... Create stored procedures ... SELECT * FROM STUDENTS ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Triggers und History
    ... Gestern habe ich mich in Dynamic SQL eingearbeitet und der Aktuelle stand ist, dass ich fast das statement erhalte was ich benötige. ... declare colCur cursor static local for ... Wobei du das entweder komplett zur Laufzeit (ggf. ... In diesen Statements könntest Du auch wieder "IF)" anstelle von "COLUMNS_UPDATED" verwenden. ...
    (microsoft.public.de.german.entwickler.dotnet.datenbank)
  • Re: Help with Stored Procedure
    ... I did mean stuff like system stored procedures (even ... build the query, compile it, and optimize it, then, then this is less ... very not easy using dynamic sql. ...
    (microsoft.public.sqlserver.programming)
  • Re: choices regarding where to place code - in the database or middle tier
    ... Sure, the DBMS is a good place for simple referential integrity constraints, ... to 4 separately-running-but-pipelined stored procedures, ... A typical user would enact a 100 or so business functions per day. ... own stored procedures' by storing the SQL for every business query in the DBMS ...
    (comp.lang.java.databases)