Existe-t-il des fonctions SQL standard avec des effets secondaires?

Les normes SQL définissent-elles des fonctions avec des effets secondaires?

Par exemple, ont-ils des fonctions pour écrire dans des fichiers * ou pour mettre à jour les valeurs dans certaines colonnes d'une table lorsque vous faites quelque chose comme

SELECT myfunction(params...);

Je les ai vus parfois, mais je suis simplement curieux de savoir si les normes SQL font de même.

_{* Il ne s'agit pas spécifiquement de PostgreSQL. J'utilise uniquement les exemples d'effets secondaires que je vois dans PostgreSQL.}

Vous avez ici quelques questions différentes.

Q: Que sont les fonctions SQL standard ANSI?

Les fonctions standard ANSI sont des choses comme AVG, COUNT, MIN, MAX. Ils sont couverts par la norme ANSI de 1992 , mais c'est une sacrée lecture sèche et ennuyeuse.

Q: Les fonctions SQL standard ANSI modifient-elles les données dans la base de données?

Non. Vous pouvez les utiliser pour modifier des données - par exemple, je peux dire:

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

Mais en eux-mêmes, l'utilisation d'AVG, COUNT, MIN, MAX, etc. ne devrait pas modifier les données de façon permanente dans votre base de données.

Q: La norme ANSI me permet-elle d'écrire mes propres fonctions?

Oui, mais l'implémentation exacte varie d'un fournisseur à l'autre. Les fonctions que vous écrivez peuvent être conformes à la norme de langage ANSI, mais ce que vous faites à l'intérieur de votre fonction peut être horriblement horrible, comme créer des effets secondaires.

• Lorsque vous discutez du comportement souhaité , il est possible d'obtenir une réponse multiplateforme.
• Lorsque vous discutez des effets secondaires , ce n'est pas le cas.

Q: Puis-je créer ma propre fonction pour écrire des données?

Bien sûr, si vous êtes créatif. Je suis un gars de Microsoft SQL Server, donc je vais me concentrer sur cette plate-forme. La page de fonction de Books Online indique:

Les fonctions définies par l'utilisateur ne peuvent pas être utilisées pour effectuer des actions qui modifient l'état de la base de données.

À quoi je dis:

Tu n'es pas mon vrai père.

Voici donc comment j'enfreindrais les règles. Attention: de très mauvaises idées suivent.

• Dans votre fonction, interrogez une nouvelle table spécialement créée à cette fin, puis créez quelque chose qui surveille la table pour les instructions de sélection, puis déclenche une action (événements étendus, audit ou trace de profileur). Vous pouvez relier une sorte d'engin Rube Goldberg pour effectuer un travail basé sur ces déclarations sélectionnées.
• Dans la fonction, appelez le code CLR - diable, vous pouvez même appeler un service Web . Ce service Web pourrait très bien repousser les données dans votre propre base de données.
• Dans la fonction, appelez xp_cmdshell et faites quelque chose via l'invite de commande. (HT @AaronBertrand dans les commentaires.)

Tous ces exemples présentent d'énormes inconvénients sous la forme de performances et de cohérence transactionnelle. Vous venez de demander si cela pouvait théoriquement être fait, et la réponse est oui. Je n'utiliserais jamais aucun de ceux-là dans mon propre code - je prendrais du recul et demanderais: "Quel est l'objectif commercial que j'essaie d'atteindre ici, et y a-t-il un moyen de le faire pour atteindre les performances et la cohérence transactionnelle ? " Si vous souhaitez des conseils spécifiques à ce sujet, je poserais une question distincte sur la pile avec des détails.

Je ne peux parler que définitivement de SQL Server, et il semble que ce ne soit pas cohérent dans toutes les implémentations de base de données. Mais dans SQL Server, les fonctions peuvent ne pas produire d'effets secondaires. C'est une règle dure et rapide que j'ai essayé de contourner un certain nombre de fois sans succès.

Si vous pensez aux fonctions au sens général, il existe des modules SQL qui autorisent les effets secondaires (par exemple les procédures stockées) mais pas les fonctions définies par l'utilisateur.

Il y a un dicton «Clever Solutions Don't Scale» qui est particulièrement vrai avec les produits Microsoft. J'ai vu un certain nombre de solutions de contournement intelligentes dans les premières versions de SQL Server qui sont devenues obsolètes dans les versions ultérieures, car MS les a ajoutées en tant que véritables fonctionnalités.

Ceux qui ne sont jamais devenus des fonctionnalités, honnêtement, ne sont jamais devenus des fonctionnalités car ils ont fondamentalement cassé un aspect du développement T-SQL. Les effets secondaires des fonctions en font partie.