sio2:la_programmation_de_declencheurs

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
sio2:la_programmation_de_declencheurs [2024/10/09 19:27] dthevenotsio2:la_programmation_de_declencheurs [2024/10/10 08:47] (Version actuelle) – [Rappels : Contraintes d’intégrité] dthevenot
Ligne 18: Ligne 18:
   * PRIMARY KEY : définit l'attribut comme la clé primaire   * PRIMARY KEY : définit l'attribut comme la clé primaire
   * UNIQUE : interdit que deux tuples de la relation aient la même valeur pour l'attribut.   * UNIQUE : interdit que deux tuples de la relation aient la même valeur pour l'attribut.
-  * REFERENCES <nom table> (<nom colonnes>) : contrôle l'intégrité référentielle entre l'attribut et la table et ses colonnes spécifiées+  * REFERENCES <nom table> (<nom colonnes>) : contrôle l'intégrité référentielle entre l'attribut et les colonnes spécifiées d'une autre table
   * CHECK (<condition>) : contrôle la validité de la valeur de l'attribut spécifié dans la condition dans le cadre d'une restriction de domaine   * CHECK (<condition>) : contrôle la validité de la valeur de l'attribut spécifié dans la condition dans le cadre d'une restriction de domaine
 =====  ===== =====  =====
 Les contraintes d'intégrité sur une table sont : Les contraintes d'intégrité sur une table sont :
-  * PRIMARY KEY (<liste d'attibuts>) : définit les attributs de la liste comme la clé primaire + 
-  * UNIQUE (<liste d'attibuts>) : interdit que deux tuples de la relation aient les mêmes valeurs pour l'ensemble des attributs de la liste. +
-  * FOREIGN KEY (<liste d'attibuts>) REFERENCES <nom table>(<nom colonnes>) : contrôle l'intégrité référentielle entre les attributs de la liste et la table et ses colonnes spécifiées +
-  * CHECK (<condition>) : contrôle la validité de la valeur des attributs spécifiés dans la condition dans le cadre d'une restriction de domaine+
 =====  ===== =====  =====
 Les différentes contraintes d’intégrité :  Les différentes contraintes d’intégrité : 
Ligne 106: Ligne 103:
    
 Si nous pouvons exécuter un programme lorsqu’un événement se produit, nous pouvons désormais, entre autres choses, vérifier des contraintes d’intégrité avancées. Et c’est ce que nous allons tâcher de montrer au travers de quelques exemples.  Si nous pouvons exécuter un programme lorsqu’un événement se produit, nous pouvons désormais, entre autres choses, vérifier des contraintes d’intégrité avancées. Et c’est ce que nous allons tâcher de montrer au travers de quelques exemples. 
 +
 +[[Exercices d'applications]]
 +
 +===== Pour conclure =====
 +En pratique, la logique métier d’un logiciel implique en général la conception ou l’évolution d’une base de données dont l’intégrité ne peut être assurée qu’au prix de nombreux contrôles. Il importe d’être capable d’identifier les contrôles à mettre en œuvre et d’établir les algorithmes nécessaires à leur mise en œuvre, qu’il s’agisse de les concevoir sous forme applicative ou sous forme de triggers.  
 +
 +===== Avantages =====
 + Les triggers permettent de mettre en œuvre des contrôles d’intégrité avancées. 
 +A l’inverse des contrôles applicatifs, lesquels nécessitent des va-et-vient entre le logiciel et le SGBD, les triggers permettent un accès direct à la base de données, ce qui améliore donc le temps de réponse de vos applications et sécurise l’accès aux données. 
 +Plus encore, l’exécution du code d’un trigger étant réalisée au sein même du SGBD, l’algorithme développé peut profiter des optimisations effectuées par le SGBD (tables d’index, fonctions de calcul optimisées, etc.).
 +=====  =====
 +Cela permet également de partager la source de données entre plusieurs applications sans rompre la logique de validation, d’intégrité de la base de données. 
 +Comme le serveur de base de données exécute des triggers, ils peuvent profiter de ressources serveur améliorées telles que la RAM et le processeur.
 +
 +En somme, l’avantage du recours aux triggers réside avant tout dans les performances qu’ils peuvent procurer. 
 +  
 +===== Inconvénients =====
 +Quoique des normes SQL existent et que les implémentations du langage SQL tendent à s’harmoniser ces dernières années, la syntaxe utilisée demeure relativement propre au SGBDR utilisé. 
 +
 +Par exemple, SQL Server dispose de sa propre implémentation, appelée Transact-SQL et souvent abrégée TSQL. De même, Oracle dispose d’une implémentation appelée PL-SQL. 
 +
 +Ainsi, la première limite des triggers réside dans le fait que le SQL avancé, celui que nous étudions dans ce cours, ne soit pas interopérable. De plus, la syntaxe SQL employée peut sembler relativement lourde en comparaison de celles des langages les plus courants (PHP, Python, Java, etc.). Finalement, ces derniers langages offrent une syntaxe souvent plus étoffée que celle du SQL. 
 +
 +===== Alternative =====
 + 
 +Un trigger n’est finalement qu’un simple programme. Et il est très fréquent de vérifier les contraintes d’intégrité de façon logicielle. On parle de contrôle logiciel ou de contrôle applicatif. Autrement dit, c’est souvent le logiciel ou les logiciels interagissant avec une base de données qui procèderont à la vérification des règles de gestion et des contraintes d’intégrité en particulier. On considérera communément que ces vérifications font partie de la logique métier. 
 +=====  =====
 +
 + Ce choix offre souvent l’avantage de la portabilité, de l’interopérabilité. Effectivement, une migration de base de données ou une duplication de la base de données vers un autre SGBD sera sans effet sur la vérification des contraintes. De surcroît, les langages de programmations actuels disposent en général d’une syntaxe plus aboutie et plus facile d’utilisation que celle proposée par la norme SQL. Plus encore, ces derniers sont souvent accompagnés de frameworks de type ORM (Object Relational Mapping) permettant de vérifier de manière élégante des contraintes d’intégrités avancées. 
  
  
  • sio2/la_programmation_de_declencheurs.1728494839.txt.gz
  • Dernière modification : 2024/10/09 19:27
  • de dthevenot