Wie kann CLR anstelle von T-SQL-Funktionen gehebelt werden, um RBARs zu vermeiden?

Question

Ich muss einige einfache Funktionen wie hisisisides, binäre Schritte, Sigmoids und verschiedene Tangenten wiederholt über einige Sätze von SQL Server-Daten ausführen. Ich habe oft gehört, dass es effizient ist, irgendwelche Mengen und Aggregate, die in solchen Funktionen verwendet werden, durch T-SQL abzuleiten, aber ineffizient, um Funktionen dieser Art wiederholt in T-SQL auszuführen. Nach dem, was ich gelesen habe, würde die Verwendung von T-SQL zu diesem Zweck nach dem populären Begriff des SQL-Server-Gurus Jeff Moden als "RBAR" -Operation oder als "Row by Agonizing Row" gelten. In verschiedenen Artikeln, die im Internet verstreut sind, habe ich oft gelesen, dass solche Funktionen in C# oder VB.Net implementiert werden sollten, aber ich bin mir nicht sicher, wie ich das genau machen und trotzdem RBARs vermeiden kann. Kann mir jemand einige Best Practices für die Verwendung von .Net-Sprachen zu diesem Zweck nennen? Dies wirft einige eng verwandte Fragen auf:

1) Kann ich dies effizient in CLR-Funktionen tun?

2) Wäre es effizienter, C# - oder VB.Net-Arrays in solchen Funktionen zu verwenden und sie massenweise ganze Datenmengen zu liefern?

3) Wie kann ich RBARs in einem solchen Design vermeiden, wenn ich die CLR-Funktionen noch einmal für jeden Datensatz im Satz aufrufen muss, genau wie bei einer normalen SQL Server-Funktion?

4) Sollte diese Logik stattdessen in Objekten der mittleren Ebene erfasst und Daten über das Netzwerk eingespeist werden?

5) Wenn ich solche Funktionen den ganzen Tag in gelegentlichen Batches ausführen muss, kann ich stattdessen ein C# - oder VB.net-Programm auf der Serverseite ausführen und es einfach kontinuierlich mit Daten versorgen? Diese Lösung könnte mit # 2 einhergehen, aber ich denke, sie könnte die Serverstabilität beeinträchtigen, wenn sie zu viel Speicher/CPU/IO außerhalb der Kontrolle von SQL Server verbrauchen würde.

Die ganze Stoßrichtung dieser Fragen ist hauptsächlich auf ein Ziel gerichtet: Den effizientesten Weg zu finden, um RBARs zu vermeiden, wenn diese Funktionen ausgeführt werden. Wenn es eine andere Methode gibt, sie zu vermeiden, die ich nicht erwähnt habe, lass es mich wissen. Ich weiß bereits, wie man einige RBARs vermeidet, indem ich T-SQL verwende, um Aggregate und Set-basierte Lösungen zu erstellen, aber ich frage mich, ob ich andere eliminieren kann, die direkt mit den wiederholenden Funktionsaufrufen in Verbindung stehen. Die beste Vorgehensweise scheint zu sein, .Net anstelle von SQL Server-Funktionen zu verwenden, um dies zu erreichen, aber ich bin unscharf, wie man das in der Praxis implementiert. Jede Hilfe würde bei der Klärung dieser Design-Entscheidung für mich geschätzt werden.

Answer 1

Nein. Eine CLR ist nur eine Funktion, die in .Net geschrieben ist und in SQL Server verfügbar gemacht wird, so dass die SQL Engine sie aufrufen kann. Sie sind im Allgemeinen weniger effizient als eine optimierte SQL-Abfrage, ermöglichen es Ihnen jedoch, Dinge zu tun, die SQL nicht kann, wie erweiterte Zeichenfolgenmanipulation oder analytische Berechnungen. Als Nebeneffekt ermöglicht CLR Web-Programmierern, Code zu erstellen, der sinnvoll ist, wenn SQL ihnen fremd ist, aber auch die satzbasierten (nicht RBAR), hocheffizienten SQL-Operationen vermeidet.

Wenn Ihre Berechnungen über den gesamten Datensatz hinausgehen, wie z. B. das durchschnittliche Gewicht eines Eichhörnchens in einer Squirrel-Datenbank, können Sie Set-basierte Aggregationen verwenden, um die Eingaben für eine CLR-Funktion zu erhalten (SELECT AVG ([Weight]) FROM dbo .SQUIRRELS), aber wenn Sie eine Berechnung für jede Zeile in den Daten benötigen, stecken Sie fest, wenn SQL die Berechnungen nicht ausführen kann.

Wenn Sie die Berechnung mithilfe von SQL ausführen können, sollten Sie eine Inline-Tabellenwertfunktion erstellen, die die Berechnung durchführt, und dann mithilfe von OUTER APPLY das berechnete Feld aktualisieren. Hier ist eine Erklärung, wenn Sie sich diese Route ansehen möchten. Rob Farley's SQL Blog.