Чи є стандартні функції SQL з побічними ефектами?

Чи визначають стандарти SQL функції з побічними ефектами?

Наприклад, чи мають вони функції запису у файли * або для оновлення значень у певних стовпцях таблиці, коли ви робите щось подібне

SELECT myfunction(params...);

Я бачив їх іноді, але мені просто цікаво, якщо стандарти SQL роблять те саме.

_{* Це не конкретно питання про PostgreSQL. Я використовую лише приклади побічних ефектів, які я бачу в PostgreSQL.}

У вас тут є кілька різних питань.

З: Що таке стандартні SQL функції ANSI?

Стандартні функції ANSI - це такі речі, як AVG, COUNT, MIN, MAX. Вони поширюються на стандарт ANSI 1992 року , але це один чорт сухого нудного прочитаного.

Питання: Чи змінюють стандартні функції ANSI SQL дані в базі даних?

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

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

Але самі по собі, лише використання AVG, COUNT, MIN, MAX тощо не повинно постійно змінювати дані всередині вашої бази даних.

Питання: Чи дозволяє стандарт ANSI мені писати власні функції?

Так, але точна реалізація варіюється від постачальника до постачальника. Функції, які ви пишете, можуть відповідати стандарту мови ANSI, але те, що ви робите всередині своєї функції, може бути жахливо жахливим, як створення побічних ефектів.

• Обговорюючи передбачувану поведінку , можна отримати відповідь між платформами.
• Обговорюючи побічні ефекти , це не так.

З: Чи можна створити власну функцію для запису даних?

Чому точно, якщо ви творчі. Я хлопець у Microsoft SQL Server, тому збираюся зосередитися на цій платформі. На сторінці функцій Books Online написано:

Визначені користувачем функції не можна використовувати для виконання дій, що змінюють стан бази даних.

На що я кажу:

Ти не мій справжній тато.

Тож ось як я порушував би правила. Попередження: випливають дуже погані ідеї.

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

Усі ці приклади мають величезні недоліки у вигляді продуктивності та транзакційної послідовності. Ви просто запитали, чи теоретично це можна зробити, і відповідь - так. Я ніколи не використовував би жодного з них у своєму власному коді - я б відступив і запитав: "Яку ділову мету я намагаюся досягти тут, і чи є спосіб, яким я можу це зробити для досягнення ефективності та послідовності транзакцій?" ? " Якщо ви хочете отримати конкретні поради щодо цих питань, я б задав окремий запит із стеком із специфікою.

Я можу лише остаточно говорити про SQL Server, і, здається, це не відповідає всім реалізаціям бази даних. Але в SQL Server функції можуть не виробляти побічних ефектів. Це важке і швидке правило, яке я намагався обійти кілька разів, не маючи успіху.

Якщо ви думаєте про функції в загальному розумінні, є модулі SQL, які дозволяють побічні ефекти (наприклад, збережені процедури), але визначені користувачем функції не виконують.

Існує приказка "Розумні рішення не масштабуйте", що особливо стосується продуктів Microsoft. Я бачив ряд розумних обхідних шляхів у ранніх версіях SQL Server, які застаріли в пізніших версіях, оскільки MS додав їх як справжні функції.

Ті, які ніколи не стали функціями, якщо чесно, ніколи не стали функціями, оскільки вони принципово порушили певний аспект розвитку T-SQL. Побічні ефекти у функціях є одним із них.