8 SQL dynamique

Le SQL dynamique est une technique de programmation qui vous permet de créer des instructions SQL de manière dynamique au moment de l’exécution. Vous pouvez créer des applications plus polyvalentes et flexibles à l’aide de SQL dynamique, car le texte intégral d’une instruction SQL peut être inconnu lors de la compilation. Par exemple, le SQL dynamique vous permet de créer une procédure qui opère sur une table dont le nom n’est pas connu avant l’exécution.

Dans les versions précédentes d’Oracle, le seul moyen d’implémenter le SQL dynamique dans une application PL / SQL était en utilisant le package DBMS_SQL. Oracle8i introduit le SQL dynamique natif, une alternative au package DBMS_SQL. En utilisant le SQL dynamique natif, vous pouvez placer des instructions SQL dynamiques directement dans des blocs PL / SQL.

Ce chapitre couvre les sujets suivants:

  • Qu’est-ce que Dynamic SQL?
  • Quand utiliser Dynamic SQL
  • Un scénario Dynamic SQL utilisant Native Dynamic SQL
  • Native Dynamic SQL vs le package DBMS_SQL
  • Application Langages de développement autres que PL / SQL

Qu’est-ce que Dynamic SQL?

Dynamic SQL vous permet d’écrire des programmes qui référencent des instructions SQL dont le texte intégral n’est pas connu avant l’exécution. Avant de discuter en détail du SQL dynamique, une définition claire du SQL statique peut fournir un bon point de départ pour comprendre le SQL dynamique. Les instructions SQL statiques ne changent pas d’une exécution à l’autre. Le texte intégral des instructions SQL statiques est connu lors de la compilation, ce qui offre les avantages suivants:

  • Une compilation réussie vérifie que les instructions SQL font référence à des objets de base de données valides.
  • Une compilation réussie vérifie que les privilèges nécessaires sont en place pour accéder aux objets de la base de données.
  • Les performances du SQL statique sont généralement meilleures que celles du SQL dynamique.

En raison de ces avantages, vous ne devriez utiliser le SQL dynamique que si vous ne pouvez pas utiliser le SQL statique pour atteindre vos objectifs, ou si l’utilisation du SQL statique est encombrante par rapport au SQL dynamique. Cependant, le SQL statique présente des limitations qui peuvent être surmontées avec le SQL dynamique. Vous ne connaissez peut-être pas toujours le texte intégral des instructions SQL qui doivent être exécutées dans une procédure PL / SQL. Votre programme peut accepter une entrée utilisateur qui définit les instructions SQL à exécuter, ou votre programme peut avoir besoin de terminer certains travaux de traitement pour déterminer le bon plan d’action. Dans de tels cas, vous devez utiliser du SQL dynamique.

Par exemple, considérons une application de création de rapports qui effectue des requêtes standard sur des tables dans un environnement d’entrepôt de données où le nom exact de la table est inconnu jusqu’à l’exécution. Pour gérer efficacement la grande quantité de données dans l’entrepôt de données, vous créez une nouvelle table chaque trimestre pour stocker les informations de facturation pour le trimestre. Ces tables ont toutes exactement la même définition et sont nommées en fonction du mois et de l’année de début du trimestre, par exemple INV_01_1997, INV_04_1997, INV_07_1997, INV_10_1997, INV_01_1998, etc. Dans un tel cas, vous pouvez utiliser dynamique SQL dans votre application de reporting pour spécifier le nom de la table au moment de l’exécution.

Avec le SQL statique, toutes les informations de définition de données, telles que les définitions de table, référencées par les instructions SQL de votre programme doivent être connues lors de la compilation. Si la définition des données change, vous devez modifier et recompiler le programme. Les programmes SQL dynamiques peuvent gérer les modifications des informations de définition des données, car les instructions SQL peuvent changer « à la volée » au moment de l’exécution. Par conséquent, le SQL dynamique est beaucoup plus flexible que le SQL statique. Dynamic SQL vous permet d’écrire du code d’application réutilisable car le code définit un processus indépendant des instructions SQL spécifiques utilisées.

De plus, le SQL dynamique vous permet d’exécuter des instructions SQL qui ne sont pas prises en charge en statique Programmes SQL, tels que les instructions DDL (Data Definition Language). La prise en charge de ces instructions vous permet d’accomplir davantage avec vos programmes PL / SQL.

Remarque:

L’expression programmes SQL dynamiques désigne les programmes qui incluent du SQL dynamique; ces programmes peuvent également inclure du SQL statique. Les programmes SQL statiques sont les programmes qui incluent uniquement du SQL statique et aucun SQL dynamique.

Quand utiliser Dynamic SQL

Vous devez utiliser Dynamic SQL dans les cas où le SQL statique ne prend pas en charge opération que vous souhaitez effectuer, ou dans les cas où vous ne connaissez pas les instructions SQL exactes qui doivent être exécutées par une procédure PL / SQL. Ces instructions SQL peuvent dépendre de l’entrée de l’utilisateur, ou elles peuvent dépendre du travail de traitement effectué par le programme. Les sections suivantes décrivent des situations typiques dans lesquelles vous devez utiliser du SQL dynamique et des problèmes typiques qui peuvent être résolus en utilisant du SQL dynamique.

Pour exécuter des instructions DML dynamiques

Vous pouvez utiliser du SQL dynamique pour exécuter Instructions DML dans lesquelles l’instruction SQL exacte n’est pas connue avant l’exécution.Pour obtenir des exemples, consultez les exemples DML dans les « Exemples de code de package DBMS_SQL et de code SQL dynamique natif » et « Exemple d’opération DML ».

Pour exécuter des instructions non prises en charge par Static SQL en PL / SQL

En PL / SQL, vous ne pouvez pas exécuter les types d’instructions suivants en utilisant du SQL statique:

  • Instructions en langage de définition de données (DDL), telles que CREATE, DROP, GRANT et REVOKE
  • Instructions de langage de contrôle de session (SCL), telles que ALTER SESSION et SET ROLE
    Voir aussi:

    Oracle8i SQL Reference pour plus d’informations sur les instructions DDL et SCL.

Utilisez du SQL dynamique si vous devez exécuter l’un de ces types d’instructions dans un PL / Bloc SQL.

De plus, le SQL statique en PL / SQL ne permet pas l’utilisation de la clause TABLE dans la SELECT instructions. Il n’y a pas de telle limitation dans le SQL dynamique. Par exemple, le bloc PL / SQL suivant contient une instruction SELECT qui utilise la clause TABLE et le SQL dynamique natif:

Pour exécuter des requêtes dynamiques

Vous pouvez utiliser le SQL dynamique pour créer des applications qui exécutent des requêtes dynamiques, qui sont des requêtes dont le texte intégral n’est pas connu avant l’exécution. De nombreux types d’applications doivent utiliser des requêtes dynamiques, notamment:

  • Les applications qui permettent aux utilisateurs de saisir ou de choisir des critères de recherche ou de tri de requête au moment de l’exécution
  • Les applications qui permettent aux utilisateurs de saisir ou choisissez des astuces d’optimisation au moment de l’exécution
  • Applications qui interrogent une base de données où les définitions de données des tables changent constamment
  • Applications qui interrogent une base de données où de nouvelles tables sont souvent créées

Pour des exemples, voir « Exemple de requête », et voir les exemples de requête dans « Un scénario SQL dynamique utilisant un SQL dynamique natif ».

Pour référencer des objets de base de données qui n’existent pas lors de la compilation

De nombreux types d’applications doivent interagir avec des données générées périodiquement. Par exemple, il peut être possible de déterminer la définition des tables de la base de données lors de la compilation, mais pas les noms des tables, car de nouvelles tables sont générées périodiquement. Votre application doit accéder aux données, mais il n’existe aucun moyen de connaître les noms exacts des tables avant l’exécution.

Le SQL dynamique peut résoudre ce problème, car le SQL dynamique vous permet d’attendre l’exécution pour spécifier le noms de table auxquels vous devez accéder. Par exemple, dans l’exemple d’application d’entrepôt de données décrit dans «Qu’est-ce que Dynamic SQL?», De nouvelles tables sont générées tous les trimestres et ces tables ont toujours la même définition. Dans ce cas, vous pouvez autoriser un utilisateur à spécifier le nom de la table lors de l’exécution avec une requête SQL dynamique similaire à la suivante:

Pour optimiser l’exécution dynamiquement

Si vous utilisez statique SQL, vous devez décider lors de la compilation comment vous voulez construire vos instructions SQL, si vous voulez avoir des indices dans vos instructions et, si vous incluez des indices, exactement quels conseils avoir. Cependant, vous pouvez utiliser le SQL dynamique pour créer une instruction SQL d’une manière qui optimise l’exécution et / ou concatène dynamiquement les indications dans une instruction SQL. Cela vous permet de modifier les indices en fonction des statistiques de votre base de données actuelle, sans nécessiter de recompilation.

Par exemple, la procédure suivante utilise une variable appelée a_hint pour autoriser les utilisateurs pour passer une option d’indication à l’instruction SELECT:

Dans cet exemple, l’utilisateur peut transmettre l’une des valeurs suivantes pour a_hint:

Pour appeler des blocs PL / SQL dynamiques

Vous pouvez utiliser EXECUTE IMMEDIATE pour appeler des blocs PL / SQL anonymes. La possibilité d’appeler des blocs PL / SQL dynamiques peut être utile pour l’extension et la personnalisation d’application où le module à exécuter est déterminé dynamiquement lors de l’exécution.

Par exemple, supposons que vous souhaitiez écrire une application qui prend un événement nombre et expédie à un gestionnaire pour l’événement. Le nom du gestionnaire se présente sous la forme EVENT_HANDLER_ event_num, où event_num est le numéro de l’événement. Une approche consisterait à implémenter le répartiteur comme une instruction switch, comme indiqué ci-dessous, où le code gère chaque événement en faisant un appel statique à son gestionnaire approprié.

Ce code n’est pas très extensible car le code du répartiteur doit être mis à jour chaque fois qu’un gestionnaire pour un nouvel événement est ajouté. Cependant, en utilisant le SQL dynamique natif, vous pouvez écrire un répartiteur d’événement extensible semblable à ce qui suit:

Pour effectuer des opérations dynamiques à l’aide des droits d’invocateur

En utilisant la fonction de droits d’invocateur avec des SQL, vous pouvez créer des applications qui émettent des instructions SQL dynamiques sous les privilèges et le schéma de l’appelant.Ces deux fonctionnalités, droits d’invocateur et SQL dynamique, vous permettent de créer des sous-composants d’application réutilisables qui peuvent fonctionner et accéder aux données et modules de l’appelant.

Voir aussi:

PL / Guide de l’utilisateur et référence SQL pour plus d’informations sur l’utilisation des droits d’invocateur et du SQL dynamique natif.

Un scénario SQL dynamique utilisant le SQL dynamique natif

Le scénario décrit dans cette section illustre la puissance et la flexibilité de SQL dynamique natif. Ce scénario comprend des exemples qui vous montrent comment effectuer les opérations suivantes à l’aide du SQL dynamique natif:

  • Exécuter des opérations DDL et DML
  • Exécuter des requêtes sur une ou plusieurs lignes

Modèle de données

La base de données dans ce scénario est la base de données des ressources humaines d’une entreprise (nommée hr) avec le modèle de données suivant :

Une table principale nommée offices contient la liste de tous les emplacements de l’entreprise. La table offices a la définition suivante :

Column Name Null? Type LOCATION NOT_NULL VARCHAR2(200)

Plusieurs tables de localisation emp_ contiennent les informations sur les employés, où lieu est le nom de la ville où le bureau est localisé. Par exemple, une table nommée emp_houston contient des informations sur les employés pour le bureau de Houston de l’entreprise, tandis qu’une table nommée emp_boston contient des employés informations sur le bureau de Boston de la société.

Chaque emp_ La table de localisation a la définition suivante:

Les sections suivantes décrivent diverses opérations SQL dynamiques natives qui peuvent être effectuées sur les données du hr base de données.

Exemple d’opération DML

La procédure SQL dynamique native suivante donne une augmentation à tous les employés avec un titre de poste particulier:

Exemple d’opération DDL

L’instruction EXECUTE IMMEDIATE peut effectuer des opérations DDL. Par exemple, la procédure suivante ajoute un emplacement de bureau:

La procédure suivante supprime un emplacement de bureau:

Exemple de requête dynamique à une seule ligne

Le EXECUTE IMMEDIATE peut effectuer des requêtes dynamiques sur une seule ligne. Vous pouvez spécifier des variables de liaison dans la clause USING et récupérer la ligne résultante dans la cible spécifiée dans la clause INTO de l’instruction.

La fonction suivante récupère le nombre d’employés à un emplacement particulier effectuant un travail spécifié:

Exemple de requête dynamique à plusieurs lignes

Le , FETCH et CLOSE peuvent effectuer des requêtes dynamiques sur plusieurs lignes. Par exemple, la procédure suivante répertorie tous les employés ayant un emploi particulier à un emplacement spécifié:

Native Dynamic SQL par rapport au package DBMS_SQL

Oracle propose deux méthodes d’utilisation du SQL dynamique dans PL / SQL: SQL dynamique natif et le package DBMS_SQL. Le SQL dynamique natif vous permet de placer des instructions SQL dynamiques directement dans du code PL / SQL. Ces instructions dynamiques incluent les instructions DML (y compris les requêtes), les blocs anonymes PL / SQL, les instructions DDL, les instructions de contrôle de transaction et les instructions de contrôle de session.

Pour traiter la plupart des instructions SQL dynamiques natives, vous utilisez EXECUTE IMMEDIATE instruction. Cependant, pour traiter une requête à plusieurs lignes (instruction SELECT), vous utilisez OPEN-FOR, FETCH et CLOSE instructions.

Remarque:

Pour utiliser le SQL dynamique natif, COMPATIBLE doit être défini sur 8.1.0 ou supérieur. Consultez Oracle8i Migration pour plus d’informations sur le paramètre COMPATIBLE.

Le package DBMS_SQL est une bibliothèque PL / SQL qui offre une API programmatique pour exécuter des instructions SQL de manière dynamique. Le package DBMS_SQL possède des interfaces de programmation pour ouvrir un curseur, analyser un curseur, fournir des liaisons, etc. Les programmes utilisant le package DBMS_SQL effectuent des appels à ce package pour effectuer des opérations SQL dynamiques.

Les sections suivantes fournissent des informations détaillées sur les avantages des deux méthodes.

Voir aussi:

Le guide et référence de l’utilisateur PL / SQL pour des informations détaillées sur l’utilisation du SQL dynamique natif et le manuel Oracle8i Fournied PL / SQL Packages Reference pour des informations détaillées sur l’utilisation de DBMS_SQL. Dans le Guide et référence de l’utilisateur PL / SQL, le SQL dynamique natif est simplement appelé SQL dynamique.

Avantages du SQL dynamique natif

Le SQL dynamique natif offre les avantages suivants par rapport au DBMS_SQL package:

Facilité d’utilisation

Le SQL dynamique natif est beaucoup plus simple à utiliser que le package DBMS_SQL.Étant donné que le SQL dynamique natif est intégré à SQL, vous pouvez l’utiliser de la même manière que vous utilisez actuellement le SQL statique dans le code PL / SQL. En outre, le code SQL dynamique natif est généralement plus compact et lisible que le code équivalent qui utilise le package DBMS_SQL.

Le DBMS_SQL n’est pas aussi facile à utiliser que le SQL dynamique natif. De nombreuses procédures et fonctions doivent être utilisées dans un ordre strict. En règle générale, l’exécution d’opérations simples nécessite une grande quantité de code lorsque vous utilisez le package DBMS_SQL. Vous pouvez éviter cette complexité en utilisant le SQL dynamique natif à la place.

Le tableau 8-1 illustre la différence dans la quantité de code requise pour effectuer la même opération en utilisant DBMS_SQL package et SQL dynamique natif.

Tableau 8-1 Comparaison du code du package DBMS_SQL et du SQL dynamique natif

Améliorations des performances

Les performances du SQL dynamique natif en PL / SQL sont comparables à celles du SQL statique car l’interpréteur PL / SQL a une prise en charge intégrée du SQL dynamique natif. Par conséquent, les performances des programmes qui utilisent SQL dynamique natif sont bien meilleures que celles des programmes qui utilisent le package DBMS_SQL. En règle générale, les instructions SQL dynamiques natives fonctionnent de 1,5 à 3 fois mieux que les instructions équivalentes qui utilisent le package DBMS_SQL. Bien entendu, vos gains de performances peuvent varier en fonction de votre application.

Le package DBMS_SQL est basé sur une API procédurale et, par conséquent, entraîne une surcharge élevée en matière d’appel de procédure et de copie de données. Par exemple, chaque fois que vous liez une variable, le package DBMS_SQL copie la variable de liaison PL / SQL dans son espace pour une utilisation ultérieure lors de l’exécution. De même, chaque fois que vous exécutez une extraction, les données sont d’abord copiées dans l’espace géré par le package DBMS_SQL, puis les données extraites sont copiées, une colonne à la fois, dans le Variables PL / SQL, entraînant une surcharge importante résultant de la copie de données. En revanche, le SQL dynamique natif regroupe les étapes de préparation, de liaison et d’exécution des instructions en une seule opération, ce qui minimise la copie de données et la surcharge des appels de procédure et améliore les performances.

Conseil sur les performances

Lorsque vous utilisez le SQL dynamique natif ou le package DBMS_SQL, vous pouvez améliorer les performances en utilisant des variables de liaison, car l’utilisation de variables de liaison permet à Oracle de partager un seul curseur pour plusieurs instructions SQL.

Par exemple, le code SQL dynamique natif suivant n’utilise pas de variables de liaison:

Pour chaque variable my_deptno distincte, un nouveau curseur est créé, qui peut entraîner des conflits de ressources et de mauvaises performances. À la place, liez my_deptno en tant que variable de liaison, comme dans l’exemple suivant:

Ici, le même curseur est réutilisé pour différentes valeurs de la liaison my_deptno, améliorant ainsi les performances et l’évolutivité.

Prise en charge des types définis par l’utilisateur

Le SQL dynamique natif prend en charge tous les types pris en charge par le SQL statique en PL / SQL. Par conséquent, le SQL dynamique natif prend en charge les types définis par l’utilisateur, tels que les objets définis par l’utilisateur, les collections et REFs. Le package DBMS_SQL ne prend pas en charge ces types définis par l’utilisateur.

Remarque:

Le package DBMS_SQL fournit une prise en charge limitée des tableaux. Pour plus d’informations, reportez-vous au manuel Oracle8i Fournied PL / SQL Packages Reference.

Prise en charge de l’extraction dans les enregistrements

Le SQL dynamique natif et le SQL statique prennent tous deux en charge l’extraction dans les enregistrements, mais le DBMS_SQL ne le fait pas. Avec le SQL dynamique natif, les lignes résultant d’une requête peuvent être directement extraites dans des enregistrements PL / SQL.

Dans l’exemple suivant, les lignes d’une requête sont extraites dans le emp_rec record:

Avantages du package DBMS_SQL

Le package DBMS_SQL offre les avantages suivants par rapport au SQL dynamique natif:

Prise en charge des programmes côté client

Actuellement, le package DBMS_SQL est pris en charge dans les programmes côté client, mais pas le SQL dynamique natif. Chaque appel au package DBMS_SQL depuis le programme côté client se traduit par un appel de procédure distante PL / SQL (RPC); ces appels se produisent lorsque vous devez lier une variable, définir une variable ou exécuter une instruction.

Prise en charge de DESCRIBE

La procédure DESCRIBE_COLUMNS dans le package DBMS_SQL peut être utilisée pour décrivez les colonnes d’un curseur ouvert et analysé via DBMS_SQL. La fonctionnalité est similaire à la commande DESCRIBE dans SQL * Plus. Le SQL dynamique natif n’a pas de fonction DESCRIBE.

Prise en charge de Bulk Dynamic SQL

Bulk SQL est la capacité de traiter plusieurs lignes de données dans une seule instruction DML. Bulk SQL améliore les performances en réduisant la quantité de changement de contexte entre SQL et le langage hôte. Actuellement, le package DBMS_SQL prend en charge le SQL dynamique en masse.

Bien qu’il n’y ait pas de prise en charge directe des opérations en masse en SQL dynamique natif, vous pouvez simuler un SQL dynamique en masse natif. en plaçant l’instruction SQL en bloc dans un bloc « BEGINEND » et en exécutant le bloc dynamiquement. Cette solution de contournement vous permet de tirer parti des avantages du SQL en masse dans un programme SQL dynamique natif. Par exemple, le code SQL dynamique natif suivant copie la colonne ename d’une table vers une autre:

Mises à jour et suppressions de plusieurs lignes avec une clause RETURNING

Le package DBMS_SQL prend en charge les instructions avec une clause RETURNING qui mettent à jour ou suppriment plusieurs lignes. Le SQL dynamique natif ne prend en charge une clause RETURNING que si une seule ligne est renvoyée.

Voir aussi:

« Exemple de retour DML » pour des exemples de DBMS_SQL code de package et code SQL dynamique natif qui utilise une clause RETURNING.

Prise en charge des instructions SQL supérieures à 32 Ko

Le DBMS_SQL le package prend en charge les instructions SQL de plus de 32 Ko; pas le SQL dynamique natif.

Réutilisation des instructions SQL

La procédure PARSE dans la DBMS_SQL analyse une fois une instruction SQL. Après l’analyse initiale, l’instruction peut être utilisée plusieurs fois avec différents ensembles d’arguments de liaison.

En revanche, le SQL dynamique natif prépare une instruction SQL à exécuter chaque fois que l’instruction est utilisée. La préparation des déclarations implique généralement l’analyse, l’optimisation et la génération de plans. La préparation d’une instruction à chaque fois qu’elle est utilisée entraîne une légère baisse des performances. Cependant, le mécanisme de curseur partagé d’Oracle minimise le coût et la pénalité en termes de performances est généralement insignifiante par rapport aux avantages en termes de performances du SQL dynamique natif.

Exemples de code de package DBMS_SQL et de code SQL dynamique natif

Les exemples suivants illustrent les différences dans le code nécessaire pour effectuer des opérations avec le package DBMS_SQL et le SQL dynamique natif. Plus précisément, les types d’exemples suivants sont présentés:

  • Une requête
  • Une opération DML
  • Une opération de retour DML

En général, le code SQL dynamique natif est plus lisible et plus compacte, ce qui peut améliorer la productivité des développeurs.

Exemple de requête

L’exemple suivant comprend une instruction de requête dynamique avec une variable de liaison (:jobname) et deux colonnes de sélection (ename et sal):

stmt_str := "SELECT ename, sal FROM emp WHERE job = :jobname";

Cet exemple de requêtes pour les employés avec le j ob description SALESMAN dans la colonne job de la table emp. Le tableau 8-2 présente un exemple de code qui accomplit cette requête à l’aide du package DBMS_SQL et du SQL dynamique natif.

Tableau 8-2 Interrogation à l’aide du package DBMS_SQL et du SQL dynamique natif

Exemple DML

Le L’exemple suivant inclut une instruction INSERT dynamique pour une table à trois colonnes:

stmt_str := "INSERT INTO dept_new VALUES (:deptno, :dname, :loc)";

Cet exemple insère une nouvelle ligne dont les valeurs de colonne se trouvent dans les variables PL / SQL deptnumber, deptname et location. Le tableau 8-3 présente un exemple de code qui accomplit cette opération DML à l’aide du package DBMS_SQL et du SQL dynamique natif.

Tableau 8-3 Opération DML à l’aide du package DBMS_SQL et SQL dynamique natif

Exemple de renvoi DML

L’exemple suivant inclut un UPDATE instruction qui met à jour l’emplacement d’un service lorsqu’on lui donne le numéro de service (deptnumber) et un nouvel emplacement (location), puis renvoie le nom du département:

stmt_str := "UPDATE dept_new SET loc = :newloc WHERE deptno = :deptno RETURNING dname INTO :dname";

Cet exemple insère une nouvelle ligne dont les valeurs de colonne sont dans les variables PL / SQL deptnumber, deptname et location. Le tableau 8-4 présente un exemple de code qui accomplit cette opération de renvoi DML à l’aide du package DBMS_SQL et du SQL dynamique natif.

Tableau 8-4 Opération de renvoi DML à l’aide de DBMS_SQL Package et SQL dynamique natif

Langages de développement d’applications autres que PL / SQL

Jusqu’à présent, la discussion de ce chapitre a été à propos de la prise en charge PL / SQL pour SQL dynamique.Cependant, vous pouvez utiliser d’autres langages de développement d’applications pour implémenter des programmes qui utilisent SQL dynamique. Ces langages de développement d’applications incluent C / C ++, COBOL et Java.

Si vous utilisez C / C ++, vous pouvez développer des applications qui utilisent SQL dynamique avec Oracle Call Interface (OCI), ou vous pouvez utiliser le précompilateur Pro * C / C ++ pour ajouter des extensions SQL dynamiques à votre C code. De même, si vous utilisez COBOL, vous pouvez utiliser le précompilateur Pro * COBOL pour ajouter des extensions SQL dynamiques à votre code COBOL. Si vous utilisez Java, vous pouvez développer des applications utilisant du SQL dynamique avec JDBC.

Dans le passé, la seule façon d’utiliser le SQL dynamique dans les applications PL / SQL était d’utiliser le DBMS_SQL. Il existe un certain nombre de limitations à l’utilisation de ce package, y compris des problèmes de performances. Par conséquent, les développeurs d’applications peuvent avoir utilisé l’une des alternatives à PL / SQL décrites ci-dessus pour implémenter le SQL dynamique. Cependant, avec l’introduction du SQL dynamique natif dans PL / SQL, de nombreux inconvénients liés à l’utilisation de PL / SQL pour le SQL dynamique sont désormais éliminés.

Si vous avez une application qui utilise OCI, Pro * C / C ++ ou Pro * COBOL pour l’exécution SQL dynamique, les allers-retours réseau nécessaires pour effectuer des opérations SQL dynamiques peuvent nuire aux performances. Étant donné que ces applications résident généralement sur des clients, davantage d’appels réseau sont nécessaires pour effectuer des opérations SQL dynamiques. Si vous disposez de ce type d’application, envisagez de déplacer la fonctionnalité SQL dynamique vers les procédures stockées et les fonctions stockées dans PL / SQL qui utilisent le SQL dynamique natif. Cela pourrait améliorer les performances de votre application car les procédures stockées peuvent résider sur le serveur, éliminant ainsi la surcharge du réseau. Vous pouvez ensuite appeler les procédures stockées PL / SQL et les fonctions stockées à partir de l’application.

Voir aussi:

Pour plus d’informations sur l’appel des procédures stockées Oracle et des fonctions stockées à partir d’applications non PL / SQL , reportez-vous à:

  • Oracle Call Interface Programmer « s Guide
  • Pro * C / C ++ Precompiler Programmer » s Guide
  • Pro * COBOL Precompiler Programmer « s Guide
  • Guide du développeur Oracle8i Java Stored Procedures

Leave a Reply

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *