Существуют ли стандартные функции SQL с побочными эффектами?

Стандарты SQL определяют функции с побочными эффектами?

Например, есть ли у них функции для записи в файлы * или для обновления значений в определенных столбцах таблицы, когда вы делаете что-то вроде

SELECT myfunction(params...);

Я видел это иногда, но мне просто любопытно, делают ли стандарты SQL то же самое.

_{* Это не вопрос конкретно о PostgreSQL. Я использую только примеры побочных эффектов, которые я вижу в PostgreSQL.}

У вас есть несколько разных вопросов здесь.

В: Что такое стандартные функции SQL ANSI?

Стандартными функциями ANSI являются такие вещи, как AVG, COUNT, MIN, MAX. Они охвачены стандартом ANSI 1992 года , но это чертовски сухое, скучное чтение.

Q: Стандартные функции SQL ANSI изменяют данные в базе данных?

Нет. Вы можете использовать их для изменения данных - например, я могу сказать:

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

Но сами по себе только использование AVG, COUNT, MIN, MAX и т. Д. Не должно постоянно изменять данные в вашей базе данных.

В: Позволяет ли стандарт ANSI мне писать свои собственные функции?

Да, но точная реализация варьируется от поставщика к поставщику. Функции, которые вы пишете, могут соответствовать стандарту языка ANSI, но то, что вы делаете внутри своей функции, может быть ужасно ужасным, например, создавать побочные эффекты.

• При обсуждении предполагаемого поведения можно получить кросс-платформенный ответ.
• При обсуждении побочных эффектов это не так.

В: Могу ли я создать свою собственную функцию для записи данных?

Да, конечно, если вы креативны. Я парень Microsoft SQL Server, поэтому я собираюсь сосредоточиться на этой платформе. Страница функций Books Online гласит:

Пользовательские функции не могут использоваться для выполнения действий, которые изменяют состояние базы данных.

На что я говорю:

Ты не мой настоящий папа.

Вот как я бы нарушил правила. Предупреждение: следуют очень плохие идеи.

• В вашей функции запросите новую таблицу, специально созданную для этой злой цели, а затем создайте что-то, что просматривает таблицу для операторов выбора, а затем запускает действие (расширенные события, аудит или трассировка профилировщика). Вы можете соединить хитрое изобретение Рубе Голдберга для выполнения работы на основе этих выбранных операторов.
• В функции вызовите код CLR - черт, вы даже можете вызвать веб-сервис . Этот веб-сервис вполне может отправить данные обратно в вашу собственную базу данных.
• В функции вызовите xp_cmdshell и сделайте что-нибудь через командную строку. (HT @AaronBertrand в комментариях.)

Все эти примеры имеют огромные недостатки в виде производительности и согласованности транзакций. Вы только что спросили, можно ли это теоретически сделать, и ответ - да. Я бы никогда не использовал ни одного из них в своем собственном коде - я отступил бы и спросил: «Какую бизнес-цель я пытаюсь здесь достичь, и есть ли способ, которым я могу сделать это для достижения производительности и согласованности транзакций?» ?» Если вы хотите получить конкретный совет по этому вопросу, я бы задал отдельный вопрос стека со спецификой.

Я могу говорить только однозначно о SQL Server, и кажется, что это не согласовано во всех реализациях базы данных. Но в SQL Server функции могут не вызывать побочных эффектов. Это жесткое и быстрое правило, которое я пытался обойти несколько раз, но безуспешно.

Если вы думаете о функциях в общем смысле, существуют модули SQL, которые допускают побочные эффекты (например, хранимые процедуры), но пользовательские функции этого не делают.

Существует поговорка «Умные решения не масштабируются», что особенно верно для продуктов Microsoft. Я видел несколько хитрых обходных путей в ранних версиях SQL Server, которые устарели в более поздних версиях, потому что MS добавила их как настоящие функции.

Честно говоря, те, которые никогда не становились функциональными возможностями, никогда не становились функциональными, потому что они в корне нарушали некоторые аспекты разработки T-SQL. Побочные эффекты в функциях является одним из них.