Ich weiß, dass wir dazu neigen, Cursor und Schleifen in SQL Server um jeden Preis zu vermeiden, aber in welchen Situationen benötigen Sie unbedingt prozedurale Abfragen, und satzbasierte Abfragen führen einfach nicht zu den Ergebnissen?
Ich verstehe den Unterschied zwischen den beiden, ich habe einfach nie zu einer Situation kommen , wo ich brauche einen Cursor zu verwenden. Ich frage mich, ob es solche Situationen gibt.
Antworten:
Nach meinen Erfahrungen bin ich einige Male darauf gestoßen, dass prozedurale / iterative Ansätze gerechtfertigt waren.
Wenn ich den Datentyp in einer Tabelle mit 500 falsch typisierten Spalten wie in dieser SO-Frage programmgesteuert von real auf dezimal ändern wollte , ist ein Cursor ein guter Ansatz, da die DDL nicht das Ändern mehrerer Spalten in einer einzelnen Anweisung ermöglicht.
Wenn Sie über das SQL Server MVP Deep Dives- Buch verfügen , enthält Kapitel 4 "Set-basierte Iteration: Die dritte Alternative" von Hugo Kornelis einige großartige Anwendungsfälle für kombinierte Cursor- / Set-basierte Operationen. Zwei der klassischen Probleme, auf die sich der Kapitelautor bezieht, sind Running Totals und Bin Packing .
Ich habe den satzbasierten Iterationsansatz mit gutem Erfolg für einen schlecht gestalteten Prozess verwendet, den ich beim letzten Job geerbt habe. Kurz gesagt, es gab einen Prozess, bei dem einmal im Jahr 50 bis 75 Millionen Zeilen aktualisiert werden mussten, und der Versuch, dies in einem einzigen Satz zu tun, würde unsere Protokolle sprengen. Durch die Aufteilung der Aktualisierungen in kleinere Stapel von N Zeilen konnte das Protokoll schneller als im Vorjahr ausgeführt werden, als nur eine Tonne mehr Speicherplatz zugewiesen wurde.
Wenn etwas nicht satzbasiert gemacht werden kann.
Blutungen natürlich offensichtlich. Beachten Sie jedoch, dass es einen Unterschied zwischen "nicht satzbasiert" und Leuten gibt, die eine prozedurale Lösung verwenden, da sie Mengen nicht verstehen oder nicht wissen, wie sie mit satzbasiertem Code umgehen sollen.
Ein Beispiel für Verfahrenscode wäre das Senden einer E-Mail pro Zeile mit unterschiedlichem Inhalt pro Zeile
Viel SQL-Code für die DBA-Verwendung ist prozedural. Beispiel: Schleifen (CURSOR oder WHILE: kein Unterschied) über Datenbanken und Tabellen, um Indizes neu zu erstellen und Statistiken zu aktualisieren.
Einige SQL-Konstrukte ermöglichen die zeilenweise Verarbeitung im Kontext einer Menge, z. B. CROSS APPLY wie folgt in SO: SELECT TOP 5-Zeilen für jeden FK (beachten Sie jedoch auch die Lösung ROW_NUMBER ()).
Bearbeiten: @ Billinkcs Antwort erweitern ...
CROSS APPLY ermöglicht satzbasierte Operationen mit UDFs, die über eine "Single Row API" verfügen.
Ich weiß, dass Sie nach SQL Server fragen, aber in der Oracle-Welt (in der Vergangenheit) waren temporäre Tabellen sehr teuer, sodass cursorbasierte Prozeduren und Trigger für den Server schneller und kostengünstiger waren. In SQL Server waren Cursor früher weitaus teurer als temporäre Tabellen, daher wurde davon abgeraten, cursorbasierten Code zu schreiben. Ich bin mir ziemlich sicher, dass diese Diskrepanzen im letzten Jahrzehnt beseitigt wurden.
Um mit diesen Situationen fertig zu werden, haben die meisten Menschen eine allgemeine Regel, um zu vermeiden, dass Geschäftslogik in die Datenbank aufgenommen wird. Wenn Sie das absolut immer tun können, gibt es weder in T-SQL noch in PL / SQL einen Grund für prozedurale Logik. Relationale Datenbanken eignen sich hervorragend für satzbasierte Logik. Die meisten modernen Programmiersprachen beherrschen die prozedurale Logik hervorragend. Es ist am besten, jeden für das zu verwenden, was er kann.
Einige Auditing-Trigger, mit denen ich gearbeitet habe, hatten ziemlich komplizierte Regeln dafür, was überprüft werden musste und wo Dinge aktualisiert / protokolliert werden mussten. Einige waren dafür gedacht, Berichtssysteme mit Transaktionssystemen synchron zu halten (es war nicht meine Wahl, aber sie wollten es so). Einige waren für ein Formelsystem . Eine Formel ist eine Liste von Arzneimitteln, und für jede Versicherungsgesellschaft, was sie abdecken / nicht abdecken und, falls verschrieben, drug_X, welche Ersatzprodukte durch die Versicherung abgedeckt sind. Es war auch üblich, dass verschiedene Gruppenpolicen bei derselben Versicherungsgesellschaft für verschiedene Medikamente bezahlten.