Consertions pour utiliser des fonctions de table pipeline dans Oracle pour implémenter la fonctionnalité de vue paramétrée?

Question

Nous avons pris la décision de superposer certaines "vues paramétrées" sur certaines vues régulières dans Oracle afin d'encourager correctement la correction où les prédicats sont toujours utilisés dans les requêtes.

La majeure partie du code répétitif (tables jointes de manière appropriée) sera dans le point de vue, afin que nous n'ayons plus de nombreuses procédures et fonctions différentes avec leurs propres copies de jointures et de filtres communs.

Ensuite, nous superposerons les fonctions de table pipeline sur ces vues pour garantir que les appelants fournissent les filtres nécessaires afin que les vues ne soient pas appelées "pour tout le temps et l'espace". J'ai examiné des alternatives à l'aide de variables SYS_Context et Userenv et de package et bien qu'ils semblent être ce que les utilisateurs d'Oracle appellent des vues paramétrées, ils ne sont tout simplement pas viables pour avoir ces cales autour d'une vue à chaque fois qu'il est utilisé et ils ne sont pas réutilisables dans auto-joins.

J'ai beaucoup lu à ce sujet dans une variété d'endroits, notamment Stackoverflow:

Fonctions à valeur de table dans Oracle 11G? (vues paramétrées)

Base de données: fonctions pipeline

L'utilisation d'une sélection à l'intérieur d'une fonction PL / SQL Pipeline est-elle autorisée?

Il s'agit d'une décision architecturale d'essayer d'améliorer la maintenabilité d'une application qui est devenue étendue avec de nombreuses requêtes répétées. Les opinions seraient en quelque sorte à aider, mais je crains que nous n'ayons aucun moyen d'appliquer les prédicats sur les appelants pour les empêcher de faire des choses idiotes.

J'ai eu beaucoup de succès en utilisant cette technique dans SQL Server avec des fonctions à valeur de table en ligne et cela a vraiment contribué au système beaucoup plus cohérent et plus facile à suivre les dépendances et les effets des modifications proposées, car il y avait un) Code moins et b) plus de réutilisation et moins de répétition.

Je suis un peu inquiet pour ce dernier lien, cela semble impliquer que je pourrais avoir des problèmes de concurrence ou de synchronisation si je devais rejoindre l'une de ces fonctions de table pipeline et l'utiliser pour mettre à jour une autre table.

Veuillez partager vos expériences avec des fonctions de table pipeline et ce que je dois rechercher? Aussi s'il existe une meilleure alternative, faites-le moi savoir également dans votre réponse?

Answer 1

Oui, le comportement ponctuel de l'interrogation d'une table dans une fonction pipeline est différent de celui de l'interrogation directement ou via une vue, il faut donc prendre en compte. Cela dit, ce n'est généralement pas un problème si la fonction pipeline interroge un tableau rarement mis à jour. Je ne peux cependant pas penser à aucun problème de concurrence ou de synchronisation.

Mon principal problème avec la fourniture de fonctions pipelinés aux développeurs à utiliser (par opposition à l'utilisation de vues), c'est qu'ils (comme certaines vues) peuvent être facilement mal utilisés. Les développeurs peuvent choisir de rejoindre les résultats d'une fonction pipeline à une autre, ce qui entraîne des requêtes très inefficaces qui ne peuvent pas profiter de choses comme des index, des prédicats poussés et des contraintes de table.

Si la maintenabilité est votre principal problème, alors je préférerais les vues - ils peuvent aider à réduire le code dupliqué en définissant des transformations courantes en un seul endroit, et peut-être également des jointures communes; Cependant, même ceux-ci sont trop facilement utilisés (par exemple, se joignant à une vue, même s'il se joint à une autre table qui n'est pas requise par la requête d'origine).

Les performances et l'efficacité seront probablement les choses à surveiller. Mettez un régime d'examen rigoureux en place pour tous les SQL de la demande pour rechercher des requêtes mal écrites ou incohérentes.