> Tech > Choisir le bon outil

Choisir le bon outil

Tech - Par iTPro - Publié le 24 juin 2010
email

Pour choisir entre ces trois solutions base de données pour le partitionnement des applications, on peut appliquer les règles générales suivantes :

  • Utiliser les déclencheurs pour mener une certaine action chaque fois qu'un événement base de données survient.
  • Utiliser les procédures stockées quand on veut contrôler la manière dont le

Choisir le bon outil

code est lancé ou pour des applications
qui requièrent des paramètres de sortie multiples.

  • Utiliser les UDF pour le traitement au niveau colonne ou si
    l’on a besoin d’appeler le code à  partir d’une interface SQL
    interactive.
  • L’un des avantages des déclencheurs est d’être lancés dès
    que l’événement base de données spécifié se produit, sans
    que le développeur puisse s’y opposer. Revers de la médaille,
    cette caractéristique des déclencheurs peut être gênante
    parce que l’application appelante ignore parfois l’existence
    du déclencheur. Pour cette raison, il vaut mieux réserver les
    déclencheurs à  des processus autonomes
    comme l’écriture d’un enregistrement
    d’audit, plutôt que de les utiliser pour des activités,
    comme la validation de données, qui
    demandent la communication entre le
    déclencheur et le programme qui l’a activé.
    Il est une autre fonction des déclencheurs
    qui est à  la fois un avantage et un inconvénient
    : un déclencheur s’activera pour chaque
    transaction du type désigné. Par exemple, si
    l’on met à  jour chaque enregistrement d’un fichier dans le
    cadre du traitement de nuit et un déclencheur update est assigné
    pour activation, il s’activera pour chaque enregistrement
    du fichier. Le seul moyen pour arrêter le traitement du
    déclencheur consiste à  supprimer et à  recréer celui-ci.
    Les déclencheurs étaient présents sur l’iSeries depuis la
    V3R1. Mais l’ajout des déclencheurs SQL en V5R1 apporte
    une excellente solution à  certains problèmes de programmation
    pour lesquels ils étaient auparavant peu pratiques. A
    titre d’exemple, considérons un déclencheur pour le fichier
    maître Customer. Malgré l’importante activité de ce fichier,
    nous ne nous intéressons qu’aux changements apportés au
    code d’état client. Avec un déclencheur externe, nous
    sommes limités à  attribuer un déclencheur update, qui s’activera
    chaque fois que le fichier sera modifié de quelque façon.
    Ensuite, dans notre programme déclencheur, nous pouvons
    vérifier si le code d’état a changé et, dans la négative,
    terminer le traitement. Cependant, ce modèle peut être inacceptable
    parce que peu performant. Un déclencheur SQL
    qui ne s’active que si le code d’état client est modifié, améliorera
    nettement la performance.
    Des trois fonctions base de données couvertes ici, les
    procédures stockées sont les plus faciles à  comprendre. En
    règle générale, on peut utiliser une procédure stockée
    chaque fois que l’on songerait à  utiliser un programme de
    service, une procédure ILE ou un appel de programme. Les
    procédures stockées sont en principe utilisées pour un traitement
    lourd spécifique aux bases de données, comme valider
    des transactions, calculer des commissions ou déterminer
    la présence d’articles en stock. Comme une procédure
    stockée est appelée explicitement et peut accepter des paramètres
    d’entrée et de sortie, elle donne plus de contrôle
    qu’un déclencheur. Cependant, contrairement aux déclencheurs,
    les procédures stockées peuvent être contournées
    ou ignorées par les développeurs d’applications. On ne peut
    donc pas utiliser des procédures stockées pour assurer l’intégrité
    des données de la même manière qu’on utiliserait des
    déclencheurs. Si l’on veut absolument que des enregistrements
    d’audit soient écrits pour chaque transaction, par
    exemple, on choisira plutôt un déclencheur qu’une procédure
    stockée.
    Les UDF sont particulièrement utiles quand on veut répéter
    une petite quantité de traitement pour chaque ligne
    qu’une instruction SQL affecte. En utilisant une UDF plutôt
    que d’écrire manuellement le code chaque fois, on garantit
    que le calcul se déroulera chaque fois de la même manière.
    Par ailleurs, les UDF permettent de gommer les incompatibilités
    existant entre des bases de données. Supposons que
    votre application actuelle utilise une base de données Oracle
    et une fonction SQL intégrée qui n’est pas disponible pour
    UDB DB2 pour iSeries. En écrivant une UDF iSeries de même
    nom que la fonction intégrée Oracle, on simplifiera la migration
    de l’application sur l’iSeries.

    Téléchargez gratuitement cette ressource

    Le Guide d’Orchestration du Parcours client

    Le Guide d’Orchestration du Parcours client

    Au-delà de la clarification des nouveaux concepts de gestion du parcours client, ce guide vous permettra de définir, créer et mettre œuvre une orchestration complète articulée autour des trois volets essentiels au succès de l’expérience client et de l’entreprise.

    Tech - Par iTPro - Publié le 24 juin 2010