La base de données
Une bonne application repose sur une bonne base de données.
Un programme utilisant cette base peut être buggé peu importe, les mécanismes internes de la base doivent faire en sorte qu'il ne soit pas possible de la corrompre.
Les possibilités qu'offrent une base sont multiples : propriétés des rubriques, cardinalités, triggers (ou procédures stockées).
Il faut à mon avis se mettre dans la tête que le programme n'est qu'une facilité pour alimenter la base et que la base doit pouvoir fonctionner de manière autonome en s'auto protégeant ! En pensant de cette manière on sait exactement ce qui doit être du ressort des programmes et ce qui doit être géré par la base, il n'y a pas d'ambiguité !
Les propriétés des rubriques :
On trouve à mon avis deux propriétes importantes : valeur nulle et unicité.
Si ces propriétés des rubriques sont bien renseignées on est déjà en mesure de limiter les erreurs. Ca peut sembler évident mais j'ai vu des bases dans lesquelles ce n'était pas respecté, les programmeurs estimant que c'est à l'applicatif de faire ces contrôles. L'un n'empêche pas l'autre.
Les triggers (ou procédures stockées) :
Pendant des années j'ai eu la facheuse tendance à utiliser des triggers WD sur des bases "évoluées" de type Oracle. Ces triggers WD sont à mon avis très bien pour du Hyper-File Classique. De plus ils permettent une simplification de l'écriture si on automatise un peu les choses (voir mon article sur les triggers).
Mais ces triggers internes WD ne sont exécutées que si on attaque la base par le programme. Il est également possible qu'un autre programme qui travaille avec cette base n'utilise pas les mêmes triggers, ou qu'il n'en utilise pas, procédant à l'affectation par du code de mise à jour (qui peut être source de problèmes). C'est un danger pour l'intégrité de la base ! Et je ne parle pas des "dépanneurs" qui vont saisir dans les tables à la "mimine", pouvant oublier de renseigner telle ou telle rubrique.
L'autre problème de triggers internes WD est qu'ils ne sont déclenchés que lors de l'exécution des fonctions de type Hajoute/Hmodifie/Hsupprime. Si vous passez par une instruction SQL (type insert, update, delate) le trigger WD ne sera pas appelé --> affectation "mimine", duplication de code, etc...
Pour moi il est évident que ces procédures doivent faire partie de la structure même de la base, au même titre qu'un index ou une relation.
Si l'application doit travailler avec des bases de plusieurs types (par exemple HFCS et Oracle) c'est un peu long à écrire à cause de syntaxes différentes (WLangage et Pl-Sql) mais cette perte de temps est préférable à celle que l'on passera par la suite à "bricoler" des données en vrac.
Pour finir je dirais que il y a un autre avantage : la vitesse d'exécution, ces triggers étant exécutés par la base elle-même sur le serveur.
Les cardinalités :
Loin de moi l'idée de faire un cours sur les cardinalités mais plutôt sensibiliser qu'il est important d'être "pointu" sur les multiplicités (0, 1, n), toujours dans le but de garantir l'intégrité de la base.
J'ai vu des bases sur lesquelles toutes les relations [1,n] étaient décrites en [0,n] et toutes les relations [1,1] en [0,1].
Pourquoi ? Tout simplement pour éviter les plantages en cas de mauvaise affectation !
Je l'ai déjà dis dans un autre article : mieux vaut un programme qui plante qu'un programme qui fait semblant de fonctionner.
Voici une énoncée toute simple mais qui peut faire la différence dans la réflexion du développeur :
Ce n'est pas à la base de se plier aux exigences du programme, mais au programme de faire avec les contraintes de la base.
Conclusion :
Il faut prendre le termps de décrire les bases avec précision. Ce temps passé sera largement récupéré lors de l'écriture et de la mise au point des applications.