Bonnes pratiques pour la création d'applications base de données

Le système de base de données va gérer votre base c'est lui qui va faire tout le travail que vous allez lui demander via vos requêtes. Il se charge aussi du stockage des données sur le disque.

Le client graphique est une application base de données qui permet d'avoir une interface graphique ergonomique pour interagir avec le système de base de données. On va l'utiliser pour créer la base, la modifier et tester les requêtes qui seront utilisées dans l'application.

Les outils de connexion sont des composants logiciels qui vont permettre de faire communiquer votre application et la base.

Personnellement j'utilise MySQL (http://dev.mysql.com/downloads/) qui permet de gérer des bases importantes. Elle est bien documentée et a des versions sur tous les OS. Son installation n'est pas très complexe. Il existe plusieurs clients graphiques pour ce système :

• PhpMyAdmin [https://www.phpmyadmin.net/], gratuit ;
• Navicat [https://www.navicat.com/fr] payant. Il a existé une version light gratuite, mais difficile à trouver maintenant.

Pour les outils de connexion, j'utilise Zeoslib (http://zeoslib.sourceforge.net/) qui est gratuit et bien supporté.

C'est le premier élément à mettre en place. Vérifiez que votre application est capable de se connecter à votre base. Surtout si vous souhaitez travailler avec une base sur une machine distante. Pour cela rien de plus simple : créer un projet et une base de données avec une table et quelques enregistrements. Dans votre projet, ajoutez le composant de connexion, configurez-le et testez si cela fonctionne. Les figures suivantes illustrent un exemple d'application de test de connexion avec des composants Zeos.

Donc on réalise une base de données avec une table.

Ensuite on crée un projet dans lequel on met en œuvre un composant de connexion (repère F).

Dans la partie gauche, on configure le composant en renseignant les propriétés (repère A à E) HostName, Password,Port, Protocol et Catalog. Puis on tente une connexion en mettant la propriété Connected (repère G) à true. En effet l'EDI Lazarus (Delphi et Cbuilder aussi) a le bon goût de faire fonctionner les composants sur l'interface ce qui permet de vérifier très rapidement le bon fonctionnement de la configuration d'un composant. Cela peut cependant présenter des inconvénients que l'on verra plus tard. Donc si tout est correctement paramétré, vous ne devez pas avoir d'erreur.

Par la suite je vous conseille de configurer votre connexion dans le code et non sur l'interface.

LaBase.Catalog:='test';
  LaBase.HostName:='localhost';
  LaBase.Password:='Pass3306';
  LaBase.Port:=3306;
  LaBase.User:='root';
  LaBase.Connected := True;

Essentiellement pour deux raisons. La première est que cela permettra de la configurer votre connexion via un fichier d'initialisation. En effet, supposons que vous distribuiez votre logiciel et que la base soit sur un serveur. Vous ne pouvez pas imposer à vos utilisateurs que le nom de leur serveur soit « ServeurBase » et vous ne pouvez pas faire une compilation par utilisateur. D'où le fichier de configuration qui permet à chaque utilisateur d'adapter la connexion à son environnement. La seconde est que vous pouvez connecter l'application au moment de votre choix et non au moment du lancement du programme.

Vous vous êtes connecté à la base. Maintenant vous allez avoir besoin de visualiser les données sur l'interface. En fonction des EDI et des langages, vous aurez accès à un certain nombre de composants vous permettant de visualiser les données et de naviguer dans les tables. Créez une table simple dans votre base qui contient des nombres, des chaînes de caractères et tous les autres types de données que vous serez amené à utiliser. Puis essayer de lire ces données à l'aide des composants logiciels. Préparez des interfaces simples pour tester et comprendre comment fonctionnent ces composants de visualisation avant de les utiliser dans votre application.

Dans l'exemple ci-dessus, on a affiché le contenu d'une table sous deux formes différentes. En haut à droite de la fenêtre figurent les composants de dialogue avec la base. À savoir le composant de connexion, un composant TDataSource (DSTable) et un composant TZTable (Table).

Le composant Table est connecté au composant connexion et la propriété TableName est renseignée avec le nom de la table dans la base. Le composant DSTable permet de faire la liaison entre la Table et les composants d'affichage et de navigation.

Vous n'allez sans doute pas vous limiter à l'affichage de vos tables. Vous allez très certainement vouloir utiliser des requêtes pour manipuler vos données. Il existe des composants qui permettent de gérer et d'exécuter des requêtes avec ou sans paramètres. Je présente ici un petit exemple réalisé avec des composants Zeos. On dispose d'une table contenant des caractéristiques de navires du XVIII^e siècle. Il s'agit d'afficher les noms des navires de la classe trois ponts.

Sur l'interface, on a le composant de connexion - un composant TdataSource (DSQuery) - et un composant TZQuery (Query) qui aura le même rôle que le composant TZtable du chapitre précédent, sauf qu'il ne se connectera pas à une table, mais on lui donnera un code SQL qui sera exécuté par le moteur de la base de données. C'est dans la propriété SQL qu'on mettra le code SQL qui sera exécuté. On a mis un composant d'affichage de type tableau sur l'interface pour visualiser le résultat de la requête. Il suffit de mettre à true le paramètre Active du composant TZQuery (Query) pour que la requête s'exécute et visualiser le résultat.

En plus clair, une table de votre base ne doit contenir que le strict minimum. Voici quelques exemples pour illustrer mon propos.

Si on réalise un carnet d'adresses, il sera bon de mettre dans une table à part le code postal ainsi que la ville correspondante.

Voici la table carnet d'adresses qu'il ne faut pas faire :

Cette table contient toutes les informations.

Voici ce qu'il vaut mieux faire :

La table Carnet

Dans cette table, il y a une référence vers une autre table qui contient les informations Code et Ville.

La table CodePostal

Chaque information code et ville est référencée par un identifiant unique.

Pourquoi cette organisation ?

Tout d'abord, un gain de place. Dans l'exemple ci-dessus, la seconde solution permet de gagner une chaîne de caractères par enregistrement. Le gain peut sembler dérisoire, mais si on a une base de quelques millions d'enregistrements, ça commence à compter. De plus la longueur des enregistrements peut avoir une influence sur les fonctions de recherche.

Ensuite cela facilite et accélère la saisie. Dans le premier cas, il faut rentrer au clavier le code postal et la ville tandis que dans le second cas ces informations sont saisies une fois puis lors de la saisie d'une autre adresse, il suffit de choisir le code et la ville dans une liste de choix.

Et enfin le plus important cela prévient un grand nombre d'erreurs et facilite corrections et mises à jour. Si pour une raison ou pour une autre les informations code postal et ville changent, il suffit de les modifier dans la table Code et toutes les adresses seront mises à jour automatiquement. Dans le cas contraire, il aurait fallu corriger chaque adresse ayant ce code postal.

Les clefs ont une grande importance dans les bases de données. Elles permettent de garantir l'unicité des informations et l'intégrité référentielle de vos tables. Dans l'exemple précédent, il serait bien d'établir une clé étrangère entre la table des codes postaux et le carnet. En effet si jamais on décide de supprimer la référence n° 1 ou si le numéro de code est changé, que va-t-il se passer avec tous les enregistrements du carnet qui contiennent cette référence. Sans clef étrangère il n'est pas possible de gérer ce type d'action.

Au cours du développement, vous serez sans doute amené à écrire des requêtes plus ou moins complexes. Pour cela, je vous conseille de les tester d'abord dans un client graphique. En effet cela simplifiera la mise au point. Si vous mettez directement votre requête dans le code, vous devrez lancer le code à chaque fois que vous voudrez vérifier si elle répond bien à vos attentes. En outre, s'il y a une erreur de syntaxe dans le SQL, cette dernière ne sera pas forcément bien signalée selon le composant que vous aurez utilisé.

Séparer dans une unité particulière tout ce qui concerne les interactions avec la base. Cela a deux avantages : le premier c'est que tout ce qui concerne la base sera regroupé au même endroit et non dispersé dans tout votre code, le second c'est que cette unité pourra être utilisée par différentes applications. Par exemple vous pouvez envisager d'accompagner votre application d'une application de maintenance qui vous permettra de travailler sur la base ou encore une application de test qui va permettre de valider des portions de logiciel.

Sous Delphi, Lazarus et CBuilder, il existe le DataModule. C'est un composant particulier qui permet de regrouper tous les composants relatifs à la base de données.

De même je vous conseille de stocker vos requêtes dans des fichiers texte dans la mesure où les composants permettent de charger la requête à partir d'un fichier. La raison est simple : vous avez mis au point votre requête dans le client graphique donc il est facile de la copier et de la sauvegarder dans un fichier texte plutôt que d'aller la programmer dans votre code.

Écrire :

QCaracSec.SQL.LoadFromFile(RepReq + 'QselectionCaracSec.sql');

est plus simple que d'écrire :

QCaracSec.SQL.Add('SELECT ST.Abreviation as st, CL.Abreviation as ct,  ');
QCaracSec.SQL.Add('MA.Acceleration as Acc, MA.Deceleration as Decc,  ');
QCaracSec.SQL.Add('CQ.SK, CQ.GunMod as gm ');
QCaracSec.SQL.Add('FROM t_speedtype as ST ');
QCaracSec.SQL.Add('JOIN t_classes as CL ');
QCaracSec.SQL.Add('on CL.RefClasse=:RefClNav ');
QCaracSec.SQL.Add('JOIN t_manoeuvrabilite as MA ');
QCaracSec.SQL.Add('on MA.RefMan=:RefManNav ');
QCaracSec.SQL.Add('JOIN t_qualequipage as CQ ');
QCaracSec.SQL.Add('on CQ.RefQualite=:RefQualNav ');
QCaracSec.SQL.Add('WHERE ST.RefSpeedType=:RefSpeedNav');

Dans le fichier QselectionCaracSec,sql figure votre requête :

SELECT ST.Abreviation as st, CL.Abreviation as ct,
MA.Acceleration as Acc, MA.Deceleration as Decc,
CQ.SK, CQ.GunMod as gm
FROM t_speedtype as ST
JOIN t_classes as CL
ON CL.RefClasse=:RefClNav
JOIN t_manoeuvrabilite as MA
ON MA.RefMan=:RefManNav
JOIN t_qualequipage as CQ
ON CQ.RefQualite=:RefQualNav
WHERE ST.RefSpeedType=:RefSpeedNav

Par ailleurs si jamais vous modifiez votre requête dans le cas où elle est inscrite en dur dans le code, vous êtes obligé de faire une compilation.

Vous avez votre DataModule et il est très facile lorsqu'on en a besoin de mettre un composant requête dessus et hop le tour est joué. Sauf qu'au bout du vingtième, vous n'y voyez plus rien et vous ne savez plus qui fait quoi (cf. figure ci-dessus). Si un composant n'est utilisé que dans une procédure (ou fonction) n'hésitez pas à le créer et à le détruire à la fin de votre procédure.

procedure TCADM.PrepareMonJournal(Ref, Tour, CodeID: integer);
var
  Query: TZquery;
begin
  Query := TZquery.Create(nil);
  Query.Connection := LaBase;
  Query.SQL.Clear;
  Query.SQL.Add('DELETE FROM t_journal');
  Query.SQL.Add(Format('WHERE NOT(RefScenario=%d AND Tour=%d AND CodeID=%d)',
    [Ref, Tour, CodeID]));
  Query.ExecSQL;
  Query.Free;
end;

Cela vous évitera en plus d'avoir des problèmes de mémoire et des lenteurs à l'initialisation.

On a vu dans le chapitre IV.C qu'il était possible de placer du code SQL directement dans l'interface lors de sa conception. C'est très pratique dans un premier temps, car cela permet de visualiser rapidement le résultat. Cependant ça peut se révéler dangereux à plus long terme. En effet, pour peu que votre projet évolue vous risquez de faire des modifications qui entraînent une erreur d'exécution d'une de vos requêtes. Dans ce cas vous risquez d'avoir des messages d'erreur assez incompréhensibles quand vous ouvrirez votre projet. Mon conseil est une fois que vous avez testé votre requête enlevez-la du paramètre SQL et mettez-la dans un fichier.

Merci à Roland Chastain pour sa relecture technique et à Claude Leloup pour ses corrections.