Oracle
 sql >> Base de données >  >> RDS >> Oracle

Est-il possible de passer le nom de la table en paramètre dans Oracle ?

Vous avez plusieurs tables différentes avec exactement les mêmes noms de colonnes et types de données ? Ça sent le design douteux.

Quoi qu'il en soit, nous ne pouvons pas utiliser de variables comme objets de base de données dans un langage SQL simple comme celui-ci. Nous devons utiliser SQL dynamique.

PROCEDURE P_CUSTOMER_UPDATE
  (
      pADSLTable IN USER_TABLES.table_name%type,
      pAccountname IN NVARCHAR2,
      pStatus IN NUMBER,
      pNote IN NVARCHAR2,
      pEmail IN NVARCHAR2,
      pMobi IN NVARCHAR2,
      pServiceTypeID IN NUMBER,
      pDate IN DATE
  )
  IS
  BEGIN
      execute immediate 
          'UPDATE '||pADSLTable
          ||' SET STATUS = :1, NOTE = :2, EMAIL = :3, MOBI = :4, SERVICETYPE_ID = :5, ACTIVATION_DATE = :6'
          ||' WHERE ACCOUNT_NAME = :7'
      using pStatus, pNote, pEmail, pMobi, pServiceTypeID, pDate, pAccountname;
  END;

L'une des raisons d'éviter l'utilisation du SQL dynamique est qu'il est ouvert aux abus. Des personnes malveillantes peuvent utiliser les paramètres pour tenter de contourner notre sécurité. C'est ce qu'on appelle l'injection SQL. Je pense que les gens surestiment l'importance de l'injection SQL. Ce n'est pas automatiquement une menace. Par exemple, si la procédure est une procédure privée dans un package (c'est-à-dire non déclarée dans la spécification), il est peu probable que quelqu'un la détourne.

Mais il est judicieux de prendre des précautions. DBMS_ASSERT est un package introduit dans Oracle 10g pour piéger les tentatives d'attaques par injection SQL. Dans ce cas, cela vaudrait la peine de l'utiliser pour valider le nom de table passé

....
'UPDATE '|| DBMS_ASSERT.simple_sql_name(pADSLTable)
....  

Cela empêcherait quiconque de passer 'pay_table set salary = salary * 10 where id = 1234 --' comme paramètre de nom de table.

Une autre raison d'éviter le SQL dynamique est qu'il est plus difficile à obtenir correctement et plus difficile à déboguer. La syntaxe de l'instruction réelle n'est vérifiée qu'au moment de l'exécution. Il est bon d'avoir une suite complète de tests unitaires qui valident toutes les entrées passées, pour s'assurer que la procédure ne déclenche pas d'exception de syntaxe.

Enfin, ce SQL dynamique n'apparaît pas dans des vues telles que ALL_DEPENDENCIES. Cela rend plus difficile d'entreprendre une analyse d'impact et de localiser tous les programmes qui utilisent une table ou une colonne donnée.