Sind CLR gespeicherte Prozeduren über TSQL gespeicherte Prozeduren in SQL 2005+ bevorzugt?

Question

Meine aktuelle Ansicht ist nein, lieber Transact gespeicherte SQL-Prozeduren, weil sie ein geringeres Gewicht und (möglicherweise) mit höherer Leistung Option sind, während CLR Verfahren Entwickler ermöglichen, auf alle Arten von Unfug zu bekommen.

Doch vor kurzem habe ich benötigt, um einige sehr schlecht geschrieben TSQL gespeicherte Prozeduren zu debuggen. Wie üblich habe ich viele der Probleme aufgrund der ursprünglichen Entwickler Entwickler, die keine echten TSQL Erfahrung gefunden, sie waren ASP.NET / C # fokussiert.

So, CLR Verfahren unter Verwendung von zunächst eine viel vertrauter Toolset für diese Art von Entwickler zur Verfügung stellen würde, und zweitens die Debug- und Testeinrichtungen sind leistungsfähiger (dh Visual Studio anstelle von SQL Management Studio).

würde ich sehr daran interessiert, zu hören Ihre Erfahrungen als es scheint es keine einfache Wahl.

Answer 1

Es gibt Orte, sowohl für gut geschriebenen, gut ausgearbeiteten T-SQL und CLR. Wenn eine Funktion aufgerufen wird, nicht häufig, und wenn es erweiterte Prozeduren in SQL Server 2000 erforderlich ist, kann CLR eine Option sein. Auch Dinge wie Berechnung läuft direkt neben den Daten können ansprechend sein. Aber die Lösung schlechte Programmierer in neuer Technologie zu werfen klingt wie eine schlechte Idee.

Answer 2

CLR gespeicherte Prozeduren sind nicht dazu gedacht, Set-basierte Abfragen zu ersetzen. Wenn Sie die Datenbank abfragen müssen, werden Sie noch brauchen SQL in Ihren CLR Code zu setzen, als ob es in regelmäßigen Code eingebettet war. Dies wäre eine vergebliche Mühe sein.

CLR gespeicherte Prozeduren sind für zwei Dinge: 1) Interaktion mit dem Betriebssystem, wie zum Beispiel aus einer Datei zu lesen oder eine Nachricht in MSMQ, und 2) Durchführung komplexe Berechnungen fällt, vor allem, wenn Sie den Code bereits in einem schriftlichen haben. NET Sprache, um die Berechnung zu tun.

Answer 3

Hosten der CLR in SQL Server soll Datenbankentwickler geben flexiblere Optionen in wie suchten sie Aufgaben zu erfüllen. Wie andere schon erwähnt haben, ist SQL groß für Operationen und Änderungen auf Sätze von Daten . Jeder, der seine Großanwendungsentwicklung mit komplexen Business / Domain-Regeln würden Sie wahrscheinlich sagen, getan hat -. Versucht zu erzwingen einige dieser Regeln mit reinem SQL (einige Male in einem einzigen Makro-Abfrage) kann wirklich alptraum bekommen

Es gibt nur bestimmte Aufgaben, die besser in einer prozeduralen oder OO Weise behandelt werden. Dadurch, dass .NET-Code die Wahl der Verwendung der Sequenz von Logik zu brechen, Abfrage-Operationen einfacher bekommen zu lesen und zu debuggen. Verwendet CLR gespeicherte Procs Ich kann Ihnen sagen, mit der Debugger Schreiten durch wirklich macht es einfacher, mit durch zu folgen, was auf Datenbankebene geschieht.

Um nur ein Beispiel verwenden wir häufig gespeicherte Procs CLR hier als „Gateway“ für die dynamische Suchanfragen. Sagen Sie auch eine Anfrage, die bis zu 30 verschiedene Suchparameter haben. Benutzer offensichtlich nicht alle 30 von ihnen verwenden, so wird die Datenstruktur bestanden in 30 Parameter haben aber meist DBNULL. Die Client-Seite hat keine Option eine dynamische Anweisung, aus offensichtlichen Sicherheitsgründen zu erzeugen. Die daraus resultierende dynamische Anweisung wird intern erzeugt, ohne Angst vor externen „Extras“.

Answer 4

In der Regel verwenden Sie die CLR, wenn Sie etwas, das nicht viel mit der Datenbank-Schnittstelle benötigt. Also lassen Sie uns sagen, Sie sind Parsen, oder einen Wert dekodieren. Dies ist einfacher, in der CLR zu tun und dann den Wert zurück.

Der Versuch, eine compelx Abfrage in der CLR zu tun, ist einfach nicht der Weg zu gehen.

BTW dies im Jahr 2008 hat auch nicht geändert werden.

Answer 5

Ich glaube, die beiden sind nicht gleichwertig ... passen gegeneinander Platz weg.
wird der CLR-Integration den Ausstieg aus der „erweiterten gespeicherten Prozeduren“ der Vorzeit soll. Wir einige von ihnen in unserem Arbeitsplatz haben ... im wesentlichen Blöcke der Verarbeitung / Logik über SQL-Daten, die zu schwer / unmöglich war, zu tun über konventionelle DB Stored Procedures / T SQL. So schrieben sie auf, als erweiterte gespeicherte Prozeduren in C ++ DLLs, die in ähnlicher Weise aufgerufen werden können. Jetzt wurden sie auslaufen und CLR-Integration ist der Ersatz

• DB Stored Procedures: wenn es in T gespeicherte SQL-Prozeduren durchgeführt werden, tun Sie es
.
• CLR Stored Procedures: Wenn die Logik ist zu komplex oder mühsam über T SQL zu tun ... Wenn es etwas, das weniger Zeilen CLR-Code übernehmen wird (String-Manipulation, komplexe / benutzerdefinierte Sortierung oder Filterung in Angriff zu nehmen, usw. verwenden) diesen Ansatz.

Answer 6

Neben dem Dateisystemzugriff (wo CLR Procs einen sehr ausgeprägten Vorteil hat) würde ich T-SQL-Procs verwenden. Wenn Sie besonders komplexe Berechnungen haben könnten Sie möglicherweise das Stück in eine CLR Funktion und rufen Sie diese aus Ihrer proc (UDF sind, wo ich die CLR-Integration wirklich glänzt gefunden habe). Dann erhalten Sie die Vorteile der CLR-Integration für diesen bestimmten Teil Ihrer Aufgabe, aber halten so viel von Ihrer gespeicherten proc-Logik in der DB wie Sie können.

Answer 7

Nach dem, was Sie gesagt haben, würde ich eher Sie die deveopers trainiert richtig bekommen in T-SQL und Datenbanken im Allgemeinen als es ihnen ermöglichen posssibly viel mehr Schaden an Leistung zu schaffen, indem sie T-SQL-Aufgaben in CLRs zu tun. Entwickler, die Datenbanken nicht verstehen, verwenden, die als Vorwand, Dinge zu tun, die Art und Weise zu vermeiden, die am besten für die Leistung der Datenbank ist, weil sie nehmen wollen, was sie als einfachen Weg zu sehen.

Answer 8

Es kommt immer auf das richtige Werkzeug für den Job, so dass es hängt wirklich davon ab, was Sie versuchen zu erreichen.

jedoch als allgemeine Regel, Sie haben Recht, dass die CLR Procs einen größeren Aufwand und wird nie auf Set-Operationen wie T-SQL ausführen. Meine Leitlinie ist alles in T-SQL tun, es sei denn, was Sie brauchen in T-SQL zu kompliziert wird. Dann versucht härter den T-SQL-Ansatz zu arbeiten. :-)

CLR Procs sind groß und haben ihren Platz, aber ihre Verwendung sollte die Ausnahme, nicht die Regel sein.

Answer 9

Die SQL Server-Online Seite zum Thema diese Listen Vorteile:

• Ein besseres Programmiermodell. Die .NET Framework-Sprachen sind in vielerlei Hinsicht reicher als Transact-SQL, konstruiert und Fähigkeiten bisher nicht zur Verfügung zu SQL Server-Entwickler bietet. Entwickler können auch die Leistung der .NET Framework-Bibliothek nutzen, die eine umfangreiche Reihe von Klassen bieten, die verwendet werden können, um schnell und effizient lösen Probleme programmieren.

• Verbesserte Sicherheit. Managed Code läuft in einer gemeinsamen Sprache Laufzeitumgebung, die von dem Datenbank-Engine gehostet. SQL Server nutzt dies in früheren Versionen zur Verfügung, die erweiterten gespeicherten Prozeduren eine sicherere Alternative zu bieten von SQL Server.

• Die Fähigkeit, Datentypen und Aggregatfunktionen zu definieren. Benutzerdefinierte Typen und benutzerdefinierte Aggregate sind zwei neue verwaltete Datenbankobjekte, die die Speicher- und Abfragefunktionen von SQL Server erweitern.

• Schlanke Entwicklung durch eine standardisierte Umgebung. Datenbankentwicklung wird in zukünftige Versionen von Microsoft Visual Studio .NET-Entwicklungsumgebung integriert. Entwickler verwenden die gleichen Werkzeuge für die Entwicklung und das Debuggen von Datenbankobjekten und Skripts, wie sie der mittleren Ebene oder Client-Tier .NET Framework-Komponenten und Dienstleistungen.

verwenden, um zu schreiben

• Potenzial für eine verbesserte Leistung und Skalierbarkeit. In vielen Situationen, die .NET Framework-Sprache Kompilierung und Ausführungsmodelle verbesserte Leistung über Transact-SQL liefern.

Answer 10

Wir liefen in eine Situation mit einer CLR-Funktion, die tausende Male in einem regulären SQL proc aufgerufen wurde. Dies war ein proc, um Daten von einem anderen System importieren. Die Funktion validiert die Daten und verarbeitet nulls gut.

Wenn wir den Betrieb in TSQL hat, beendet die Prozedur in etwa 15 Sekunden. Wenn wir die CLR-Funktion verwendet wird, beendet die Prozedur in 20 bis 40 Minuten. Die CLR-Funktion sah eleganter, aber soweit wir sagen können, es war ein Start-up für jede Verwendung der CLR-Funktion getroffen. Also, wenn Sie eine große Operation mit einer CLR-Funktion durchgeführt, das ist in Ordnung, da die Startzeit klein ist im Vergleich zu der Zeit, die für den Betrieb. Oder wenn Sie ein, die CLR-Funktion eine bescheidene Anzahl von Malen, die Gesamtstartzeit für alle Aufrufe der Funktion aufrufen wäre klein. Aber seien Sie vorsichtig von Schleifen.

Auch für Wartbarkeit, ist es schöner nicht mehr Sprachen zu haben, als Sie wirklich brauchen.

Answer 11

Ich würde ein paar Gründe hinzufügen CLR zu verwenden, die nicht erwähnt wurden.

• Ersetzen und grundlegende Abfrage, nicht-Abfrage und skalare SQL-Funktionen erweitern.
  A) Fehlerberichte und Warnungen können basierend auf festgelegten Anforderungen integriert werden. B) definieren Leicht Ebenen debuggen. C) Aktivieren Sie einen einfacheren Weg mit ausländischen SQL Server zu interagieren
• Verschieben Legacy-Code zu einer verwalteten Umgebung.

Answer 12

Ich gab folgende Antwort auf eine ähnliche Frage: Vorteil SERVER CLR SQL . Ich werde hier allerdings hinzufügen, dass C # / VB.net / etc ist eine Sprache, jemand wohler mit ist als T-SQL sollte nicht ein Grund sein, verwenden SQLCLR über T-SQL. Wenn jemand nicht weiß, wie etwas in T-SQL zu erreichen, zuerst um Hilfe bitten, eine T-SQL-Lösung zu finden. Wenn man nicht existiert, und geht die CLR Route.

---

SQLCLR / CLR-Integration in SQL Server ist nur ein weiteres Werkzeug, um bestimmte zu lösen (nicht alle) Probleme. Es gibt ein paar Dinge, dass es funktioniert besser als das, was in der reinen T-SQL durchgeführt werden, und es gibt einige Dinge, die nur über SQLCLR getan werden können. Ich schrieb einen Artikel für SQL Server Central, Stairway to SQLCLR Ebene 1: Was ist SQLCLR? (kostenlose Registrierung erforderlich Artikel dort zu lesen), die diese Frage anspricht. Die Grundlagen sind (die verlinkten Artikel für Details):

• Streaming-Tabellenwertfunktionen (STVF)
• Dynamische SQL (innerhalb Funktionen)
• Besserer Zugriff auf externe Ressourcen / Ersetzen xp_cmdshell
  • Übergeben von Daten in einfacher
  • Ankommen mehrere Spalten einer Ergebnismenge zurück ist einfacher
  • Keine externen Abhängigkeiten (z 7zip.exe)
  • Bessere Sicherheit über Identitätswechsel
• Die Fähigkeit, Multi-Thread
• Fehlerbehandlung (innerhalb Funktionen)
• Benutzerdefinierte Aggregate
• Benutzerdefinierte Typen
• Ändern Staat (innerhalb einer Funktion und ohne OPENQUERY / OPENROWSET)
• Führen Sie eine Stored Procedure (schreibgeschützt, innerhalb einer Funktion und ohne OPENQUERY / OPENROWSET)
• Performance ( Hinweis: Das ist nicht Bedeutung in allen Fällen, aber auf jeden Fall in einigen Fällen von der Art und Komplexität des Betriebes abhängig)
• Kann Ausgang erfassen (also das, was auf die Registerkarte Nachrichten in SSMS gesendet wird) (zB PRINT und RAISERROR mit einem Schwere = 0 bis 10) - Ich habe vergessen, diese in dem Artikel zu erwähnen, -).

Eine andere Sache zu prüfen ist, manchmal ist es von Vorteil ist, in der Lage sein Code zwischen der App zu teilen und die DB, so dass die DB Einblick in bestimmte Geschäftslogik hat ohne individuelle bauen zu müssen, nur den internen Bildschirme nur, dass für den Zugriff auf App-Code. Zum Beispiel habe ich auf einem System gearbeitet, die Datendateien von Kunden importiert und einen benutzerdefinierten Hash meisten Felder verwenden und gespeichert diesen Wert auf die Zeile in der DB. Dies ermöglichte leicht Zeilen des Überspringen, wenn ihre Daten wieder als app Import würde die Werte aus der Eingabedatei Hash- und mit dem Hash-Wert in der Zeile gespeicherten zu vergleichen. Wenn sie gleich dann waren wussten wir sofort, dass keines der Felder verändert hatte und so gingen wir auf die nächsten Zeile, und es war ein einfacher INT Vergleich. Aber das Algorithmus für den Hash tut nur im App-Code war so, ob für das Debuggen eines Kunden Fall oder auf der Suche nach Möglichkeiten, einige Verarbeitung abzuladen Back-End-Service von Zeilen des Markieren, die mit Änderungen mindestens ein Feld hatten (Änderungen kommen aus unserer App wie in einer neueren Importdatei für Änderungen suchen Gegensatz), gab es nichts, was ich tun konnte. Das wäre eine große Chance gewesen, ein ziemlich einfach bisschen Business-Logik in der DB zu haben, wenn auch nicht für die normale Verarbeitung; zu haben, was ohne Fähigkeit, in der DB zu einem codierten Wert beträgt seine Bedeutung macht es viel schwer zu lösen Probleme zu verstehen.

Wenn Sie interessiert sind in einigen dieser Fähigkeiten in Aktion zu sehen, ohne Code schreiben zu müssen, die kostenlose Version von SQL # (von denen ich bin der Autor) hat RegEx-Funktionen, benutzerdefinierte Aggregate (UDA), benutzerdefinierte Typen (UDT), etc.