Utiliser des contraintes pour assurer l’intégrité des données

mais elles sont plus faciles à 
mettre en oeuvre et elles offrent des performances
optimales en matière de vérifications
de l’intégrité des données qui
correspondent à  leur définition relativement
étroite.

Dans tous les cas, l’imposition de
contraintes peut être comparée à  l’imposition
de règles de clés en double: la base
de données s’assure absolument qu’aucune
donnée corrompue ne sera stockée,
mais le concepteur de l’application
doit isoler l’utilisateur final des erreurs
entraînées par la violation d’une
contrainte.

Dans l’idéal, il faudrait ôter du code
d’application toute règle d’intégrité qui
peut être traitée par une contrainte et la
recréer comme une contrainte. Les avantages
de cette méthode sont multiples:
meilleures performances, modèle d’application
plus modulaire, et assurance de
l’imposition de la contrainte, indépendamment
de la source de la transaction.
Dès lors qu’une contrainte est là  pour imposer
une règle de gestion, les règles
d’intégrité des données de base perdurent
si l’on crée une nouvelle application.

Malheureusement, enlever des
règles d’intégrité hors des applications
pour les mettre dans des contraintes ne
va pas sans difficultés. Tout d’abord, le
code d’application existant ne contrôle
pas les violations des contraintes. On
peut certes le réécrire, mais ce n’est pas
le meilleur moyen d’utiliser les ressources
de modernisation des applications.