Gibt es Standard-SQL-Funktionen mit Nebenwirkungen?

Definieren die SQL-Standards Funktionen mit Nebenwirkungen?

Haben sie beispielsweise Funktionen zum Schreiben in Dateien * oder zum Aktualisieren von Werten in bestimmten Spalten einer Tabelle, wenn Sie so etwas tun?

SELECT myfunction(params...);

Ich habe diese manchmal gesehen, aber ich bin nur neugierig, ob die SQL-Standards dasselbe tun.

_{* Dies ist keine Frage zu PostgreSQL. Ich verwende nur die Beispiele für Nebenwirkungen, die ich in PostgreSQL sehe.}

Sie haben hier ein paar verschiedene Fragen.

F: Was sind ANSI-Standard-SQL-Funktionen?

ANSI-Standardfunktionen sind Dinge wie AVG, COUNT, MIN, MAX. Sie sind im ANSI-Standard von 1992 enthalten , aber das ist eine verdammt trockene, langweilige Lektüre.

F: Ändern ANSI-Standard-SQL-Funktionen Daten in der Datenbank?

Sie können sie verwenden, um Daten zu ändern - zum Beispiel kann ich sagen:

INSERT INTO dbo.MyReport SELECT MAX(SalespersonRevenue) FROM dbo.Sales

Allein die Verwendung von AVG, COUNT, MIN, MAX usw. sollte die Daten in Ihrer Datenbank nicht dauerhaft ändern.

F: Erlaubt mir der ANSI-Standard, meine eigenen Funktionen zu schreiben?

Ja, aber die genaue Implementierung variiert von Anbieter zu Anbieter. Die Funktionen, die Sie schreiben, entsprechen möglicherweise dem ANSI-Sprachstandard, aber was Sie in Ihrer Funktion tun, kann schrecklich schrecklich sein, z. B. Nebenwirkungen verursachen.

• Bei der Erörterung des beabsichtigten Verhaltens ist es möglich, eine plattformübergreifende Antwort zu erhalten.
• Bei der Diskussion von Nebenwirkungen ist dies nicht der Fall.

F: Kann ich meine eigene Funktion zum Schreiben von Daten erstellen?

Warum sicher, wenn Sie kreativ sind? Ich bin ein Microsoft SQL Server-Typ, daher werde ich mich auf diese Plattform konzentrieren. Auf der Funktionsseite von Books Online heißt es:

Benutzerdefinierte Funktionen können nicht zum Ausführen von Aktionen verwendet werden, mit denen der Datenbankstatus geändert wird.

Zu dem sage ich:

Du bist nicht mein richtiger Vater.

Also hier ist, wie ich die Regeln brechen würde. Achtung: Es folgen sehr schlechte Ideen.

• Fragen Sie in Ihrer Funktion eine neue Tabelle ab, die speziell für diesen bösen Zweck erstellt wurde, und erstellen Sie dann etwas, das die Tabelle auf ausgewählte Anweisungen überwacht, und lösen Sie dann eine Aktion aus (Erweiterte Ereignisse, Überwachung oder Profiler-Ablaufverfolgung). Sie können eine Art Rube Goldberg-Gerät miteinander verbinden, um Arbeiten basierend auf diesen ausgewählten Anweisungen auszuführen.
• Rufen Sie in der Funktion CLR-Code auf - zum Teufel können Sie sogar einen Webdienst aufrufen . Dieser Webdienst könnte Daten sehr gut in Ihre eigene Datenbank zurückschieben.
• Rufen Sie in der Funktion xp_cmdshell auf und tun Sie etwas über die Eingabeaufforderung. (HT @AaronBertrand in den Kommentaren.)

Alle diese Beispiele haben große Nachteile in Form von Leistung und Transaktionskonsistenz. Sie haben gerade gefragt, ob dies theoretisch möglich ist, und die Antwort dort lautet ja. Ich würde keines davon in meinem eigenen Code verwenden - ich würde zurücktreten und fragen: "Was ist das Geschäftsziel, das ich hier erreichen möchte, und gibt es eine Möglichkeit, dies zu tun, um Leistung und Transaktionskonsistenz zu erreichen ? " Wenn Sie spezielle Ratschläge dazu wünschen, würde ich eine separate Stapelfrage mit Einzelheiten stellen.

Ich kann nur definitiv über SQL Server sprechen, und es scheint, dass dies nicht bei allen Datenbankimplementierungen konsistent ist. In SQL Server können Funktionen jedoch keine Nebenwirkungen hervorrufen. Dies ist eine feste Regel, die ich mehrmals ohne Erfolg zu umgehen versucht habe.

Wenn Sie über Funktionen im allgemeinen Sinne nachdenken, gibt es SQL-Module, die Nebenwirkungen zulassen (z. B. gespeicherte Prozeduren), benutzerdefinierte Funktionen jedoch nicht.

Es gibt ein Sprichwort "Clever Solutions Don't Scale", das insbesondere für Microsoft-Produkte gilt. Ich habe in früheren Versionen von SQL Server eine Reihe cleverer Problemumgehungen gesehen, die in späteren Versionen veraltet waren, weil MS sie als echte Funktionen hinzugefügt hat.

Diejenigen, die ehrlich gesagt nie zu Features wurden, wurden nie zu Features, weil sie einen Aspekt der T-SQL-Entwicklung grundlegend brachen. Nebenwirkungen in Funktionen sind eine davon.