Mittendrin.

Zurück

Flurfunk der eXperts.

Hier erfahren Sie mehr über eXperts, Technologien und das wahre Leben in der SDX.

Stored Procedures sind keine parametrisierten Views

12.11.201010:50 Uhr , Nicolas Meseth

Der Titel dieses Blogeintrags stammt im Original von Adam Machanic – ich habe mir erlaubt, den Titel seines Beitrags zu diesem Thema originalgetreu in die Deutsche Sprache zu übersetzen. Ich finde er trifft es sehr gut: http://sqlblog.com/blogs/adam_machanic/archive/2006/07/12/stored-procedures-are-not-parameterized-views.aspx

Schon oft habe ich mich gefragt, warum in der Praxis so häufig Stored Procedures (SP) für den gekapselten Datenzugriff verwendet werden, wenn die Abfrage parametrisiert sein muss. Das ist z.B. der Fall, wenn ich meine Ergebnisse zeitlich filtern möchte. In diesem Fall wird z.B. häufig eine SP entworfen, die zwei Parameter @FromDate und @ToDate besitzt, und in der eine einfache Abfrage ausgeführt wird, deren Ergebnis mit Hilfe dieser Parameter in der WHERE-Bedingung eingeschränkt wird. In der Regel funktioniert das auch sehr gut, aber warum wird anstatt einer SP nicht das eigentlich vom SQL Server dafür vorgesehene Objekt verwendet: Die Table-Valued Function? Die Table-Valued Function hat zwei gravierende Vorteile gegenüber einer SP:

  1. Eine Function definiert explizit die Metadaten der Rückgabe, d.h. alle Spalten sind mit Name und Datentyp definiert, und die Anwendung, die die Funktion verwendet, hat vollen Zugriff auf diese Metadaten. Bei einer SP ist das nicht immer der Fall. Z.B. wenn innerhalb der SP eine temporäre Tabelle für die Zwischenspeicherung verwendet wird, kann es sein, dass die Metadaten der Abfrage nicht ermittelt werden können. In SSIS oder SSRS führt dies dazu, dass die Data Source bzw. das Data Set keine Informationen bezüglich der zurückgegebenen Spalten erhält.
  2. Functions können in Select-Statements verwendet werden. Während mit einer SP der folgende Aufruf nicht möglich wäre, SELECT ID, Name FROM SP_XY; funktioniert Gleiches, wenn eine Function verwendet wird. Eine Function ermöglicht somit eine direkte Selektion ihres eigenen Rückgabesets.

An dieser Stelle also der Appell, den Table-Valued Functions eine Chance zu geben, das zu tun, wofür sie erfunden wurden, und SPs nicht für etwas zu missbrauchen, für das sie nicht gedacht sind!

1 Kommentar

12.11.201011:56 Uhr
Nicolas Meseth

Ein Update hierzu: Table-Valued Functions sind nur dann einsetzbar, wenn keine Logik benötigt wird, die eine Fehlerbehandlung braucht. Dinge wie TRY /CATCH oder RAISEERROR funktionieren nur in SPs.

Für wirklich reine parametrisierte Views sind sie aber hervorragend geeignet.

Dein Kommentar wartet auf Freischaltung.

Artikel kommentieren

Zurück

Tag Cloud


Kontakt aufnehmen


Anrufen

Gerne beantworten wir Ihre Fragen in einem persönlichen Gespräch!


Kontakt aufnehmen

Schreiben Sie uns eine E-Mail mit Ihren Fragen und Kommentaren!