Unterschied zwischen einer Inline-Funktion und einer Ansicht

Question

Ich bin ein Neuling in der Verwendung von Funktionen und es scheint mir, dass eine Inline-Funktion einer Ansicht sehr ähnlich ist. Liege ich richtig?

Kann ich auch UPDATE-Anweisungen innerhalb einer Funktion haben?

Answer 1

Nachdem ich viele der Antworten hier gelesen habe, möchte ich anmerken, dass es einen großen Unterschied zwischen einer Inline-Tabellenfunktion und jeder anderen Art von Funktion (skalare oder mehrzeilige TVF) gibt.

Eine Inline-TVF ist einfach eine parametrisierte Ansicht. Sie kann genau wie eine Ansicht erweitert und optimiert werden. Es ist nicht erforderlich, irgendetwas zu materialisieren, bevor man "Ergebnisse zurückgibt" oder ähnliches (obwohl die Syntax leider eine RETURN .

Ein großer Vorteil, den ich bei einer Inline-TVF gegenüber einer View gefunden habe, ist, dass sie die erforderliche Parametrisierung erzwingt, während man bei einer View davon ausgehen muss, dass der Aufrufer die Verwendung der View angemessen verbinden oder einschränken wird.

Wir haben zum Beispiel viele große Faktentabellen in DW mit einem typischen Kimball-Sternmodell. Ich habe eine Ansicht auf ein faktentabellenzentriertes Modell, die, wenn sie ohne jede Einschränkung aufgerufen wird, Hunderte von Millionen von Zeilen zurückgibt. Durch die Verwendung einer Inline-TVF mit entsprechender Parametrisierung können die Benutzer nicht versehentlich alle Zeilen abfragen. Die Leistung ist zwischen den beiden weitgehend ununterscheidbar.

Answer 2

Kein Unterschied. Sie werden beide in die enthaltende Abfrage erweitert/entschachtelt.

Hinweis: Indizierte Ansichten werden anders betrachtet, können aber dennoch erweitert werden, und mehrwertige Tabellenfunktionen sind Blackboxes für die enthaltende Abfrage.

Tony Rogerson: VIEWS - sie bieten keine Optimierungsvorteile; sie sind einfach Inline-Makros - sparsam verwenden

Adam Machanic: Skalare Funktionen, Inlining und Leistung: Ein unterhaltsamer Titel für einen langweiligen Beitrag

Verwandte SO Frage: Funktioniert der Abfrageplanoptimierer gut mit verbundenen/gefilterten tabellenwertigen Funktionen?

Beängstigende DBA (am Ende)

Schließlich sind Schreibvorgänge in Tabellen in Funktionen nicht erlaubt

Edit, nach Eric Z Beard's Kommentar und Downvote...

Die Fragen und Antworten (nicht nur meine) beziehen sich nicht auf skalare udfs. "Inline" bedeutet "Inline-Funktionen mit Tabellenwert". Sehr unterschiedliche Konzepte...

Answer 3

Aktualisierung: Es sieht so aus, als hätte ich den "Inline"-Teil übersehen. Allerdings lasse ich die Antwort hier, falls jemand über den Unterschied zwischen VIEWs und regulären Funktionen lesen möchte.

Wenn Sie nur eine Funktion haben, die SELECT ausführt und die Daten ausgibt, dann sind sie ähnlich. Aber selbst dann sind sie nicht gleich, weil VIEWs von der Engine optimiert werden können. Wenn Sie z. B. SELECT * FROM view1 WHERE x = 10; ausführen und einen Index auf einem Tabellenfeld haben, das X entspricht, wird dieser verwendet. Andererseits baut die Funktion vor der Suche eine Ergebnismenge auf, so dass Sie WHERE innerhalb der Funktion verschieben müssen. Dies ist jedoch nicht einfach, da Sie viele Spalten haben könnten und nicht alle in derselben Select-Anweisung ORDER BY sein können.

Wenn Sie also Ansichten und Funktionen für dieselbe Aufgabe vergleichen, nämlich eine "Sicht" auf Daten zu geben, dann sind VIEWs die bessere Wahl.

ABER, Funktionen können noch viel mehr. Sie können mehrere Abfragen durchführen, ohne dass Sie Tabellen mit JOINS oder UNIONs verbinden müssen. Sie können einige komplexe Berechnungen mit den Ergebnissen durchführen, zusätzliche Abfragen starten und Daten an den Benutzer ausgeben. Funktionen sind eher wie gespeicherte Verfahren, die Datensätze zurückgeben können, als wie Ansichten.

Answer 4

Diesen Aspekt scheint niemand erwähnt zu haben.

Sie können nicht haben Update Aussagen in eine Inline-Funktion, aber Sie können schreiben Update Aussagen gegen als ob sie eine aktualisierbare Ansicht wären.

Answer 5

Ein großer Unterschied besteht darin, dass eine Funktion Parameter annehmen kann, eine VIEW hingegen nicht.

Ich neige dazu, VIEWs zu bevorzugen, da es sich um eine Standardimplementierung handelt und somit portabel ist. Ich verwende Funktionen, wenn die entsprechende VIEW ohne eine WHERE-Klausel sinnlos wäre.

Ich habe z. B. eine Funktion, die eine relativ große Tabelle mit den Gültigkeitszeiten abfragt (Tabelle "history"). Wenn dies eine VIEW wäre und Sie versuchen würden, sie ohne eine WHERE-Klausel abzufragen, würden Sie eine ganze Menge fairer Daten erhalten (letztendlich!) Die Verwendung einer Funktion stellt einen Vertrag her, dass Sie eine Kunden-ID, ein Start- und ein Enddatum angeben müssen, wenn Sie die Daten haben wollen, und die Funktion ist die Art und Weise, wie ich diesen Kontakt herstelle. Warum nicht ein gespeicherter Prozess? Nun, ich erwarte, dass ein Benutzer die Ergebnismenge mit weiteren Daten (Tabellen, VIEWs, Funktionen usw.) verknüpfen möchte, und eine Funktion ist IMO die beste Möglichkeit, dies zu tun, anstatt dass der Benutzer die Ergebnismenge in eine temporäre Tabelle schreiben muss.