Czy istnieją standardowe funkcje SQL z efektami ubocznymi?

Czy standardy SQL definiują funkcje z efektami ubocznymi?

Na przykład, czy mają funkcje do zapisywania w plikach * lub do aktualizowania wartości w niektórych kolumnach tabeli, gdy robisz coś podobnego

SELECT myfunction(params...);

Czasem je widziałem, ale jestem ciekawy, czy standardy SQL robią to samo.

_{* To nie jest pytanie dotyczące PostgreSQL. Używam tylko przykładów efektów ubocznych, które widzę w PostgreSQL.}

Masz tutaj kilka różnych pytań.

P: Jakie są standardowe funkcje SQL ANSI?

Standardowe funkcje ANSI to między innymi AVG, COUNT, MIN, MAX. Są one objęte standardem ANSI z 1992 r. , Ale to jedna z nudnych, nudnych lektur.

P: Czy standardowe funkcje SQL ANSI zmieniają dane w bazie danych?

Nie. Możesz ich użyć do zmiany danych - na przykład mogę powiedzieć:

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

Ale same w sobie użycie AVG, COUNT, MIN, MAX itp. Nie powinno zmieniać danych na stałe w bazie danych.

P: Czy standard ANSI pozwala mi pisać własne funkcje?

Tak, ale dokładna implementacja różni się w zależności od dostawcy. Funkcje, które piszesz, mogą być zgodne ze standardem językowym ANSI, ale to, co robisz wewnątrz swojej funkcji, może być przerażająco okropne, jak tworzenie efektów ubocznych.

• Omawiając zamierzone zachowanie , można uzyskać odpowiedź na wiele platform.
• Podczas omawiania skutków ubocznych tak nie jest.

P: Czy mogę utworzyć własną funkcję do zapisywania danych?

Dlaczego na pewno, jeśli jesteś kreatywny. Jestem facetem Microsoft SQL Server, więc skupię się na tej platformie. Strona funkcji Books Online mówi:

Funkcje zdefiniowane przez użytkownika nie mogą być używane do wykonywania działań, które modyfikują stan bazy danych.

Do czego mówię:

Nie jesteś moim prawdziwym tatą.

Oto jak złamałbym zasady. Ostrzeżenie: następują bardzo złe pomysły.

• W swojej funkcji zapytaj o nową tabelę stworzoną specjalnie dla tego złego celu, a następnie utwórz coś, co będzie obserwować tabelę pod kątem instrukcji select, a następnie uruchomi akcję (zdarzenia rozszerzone, inspekcja lub śledzenie Profiler). Możesz połączyć urządzenie Rube Goldberga, aby wykonywać pracę na podstawie tych wybranych instrukcji.
• W funkcji wywołaj kod CLR - do diabła, możesz nawet zadzwonić do serwisu internetowego . Ta usługa sieciowa mogłaby bardzo dobrze wypychać dane z powrotem do własnej bazy danych.
• W funkcji wywołaj xp_cmdshell i zrób coś za pomocą wiersza poleceń. (HT @AaronBertrand w komentarzach.)

Wszystkie te przykłady mają ogromne wady w postaci wydajności i spójności transakcyjnej. Właśnie zapytałeś, czy można to zrobić teoretycznie, a odpowiedź brzmi tak. Nigdy bym nie użył żadnego z nich we własnym kodzie - cofnęłam się i spytałam: „Jaki cel biznesowy staram się osiągnąć tutaj i czy mogę to zrobić, aby osiągnąć wydajność i spójność transakcyjną ? Jeśli chcesz uzyskać szczegółowe porady na ich temat, zadam osobne pytanie stosu ze szczegółami.

Mogę tylko zdecydowanie wypowiedzieć się na temat programu SQL Server i wydaje się, że nie jest to spójne we wszystkich implementacjach bazy danych. Ale w SQL Server funkcje mogą nie powodować skutków ubocznych. To jest twarda i szybka reguła, którą wielokrotnie próbowałem obejść bezskutecznie.

Jeśli myślisz o funkcjach w sensie ogólnym, istnieją moduły SQL, które pozwalają na efekty uboczne (na przykład procedury składowane), ale funkcje zdefiniowane przez użytkownika nie.

Jest takie powiedzenie „Clever Solutions Don't Scale”, które jest szczególnie prawdziwe w przypadku produktów Microsoft. Widziałem wiele sprytnych obejść we wczesnych wersjach SQL Server, które stały się przestarzałe w późniejszych wersjach, ponieważ MS dodało je jako prawdziwe funkcje.

Te, które nigdy nie stały się funkcjami, szczerze mówiąc, nigdy nie stały się funkcjami, ponieważ zasadniczo złamały jakiś aspekt rozwoju T-SQL. Jednym z nich są skutki uboczne w funkcjach.