Typage

Le typage consiste à donner à chaque colonne de la table un type bien précis en fonction des données qui va recevoir. Ça ne sert à rien de déclarer une colonne comme « INT » alors que les données nécessitent uniquement un « Tinyint ». En adoptant cette stratégie pour les autres types de données, la taille de la base de données va être divisée par 2 voire même par 3.

Utilisation des contraintes

Une contrainte d’intégrité est une règle sur la table qui permet d’assurer que les données stockées dans la base de données soient cohérentes par rapport à leur signification. On peut implémenter plusieurs contraintes d’intégrité

• Au niveau de la table : Lorsque la contrainte porte sur plusieurs colonnes simultanément

(clé primaire composée), il est obligatoire de déclarer la contrainte sur la table.

• Au niveau de la colonne : se fait pour l’ensemble des contraintes à condition qu’elle porte sur une seule colonne.

Il y a plusieurs types de contraintes :

1.      PRIMARY KEY : permet de définir une clé primaire sur la table.

2.      FOREIGN KEY: cette contrainte indique que la valeur de l’attribut correspond à une valeur d’une clé primaire d’une autre table.

3.      CHECK : Indique les valeurs permises qui peuvent être saisies pour la colonne

4.      DEFAULT : indique la valeur par défaut que prendra l’attribut si aucune valeur n’est saisie.

5.      NOT NULL : indique que la valeur de la colonne ou de l’attribut est obligatoire.

6.      UNIQUE : indique que les valeurs saisie doivent être unique (pas de doublons).

Exemple :

Procédures stockées

Faut-il oui ou non utiliser des procédures ou fonctions stockées ? La question a souvent été soulevée et donne lieu à chaque fois à de vifs échanges entre pro et anti.

Sur internet on peut trouver deux avis différents sur l’utilisation ou non des procédures stockées, de ceux qui ont gagné de performance en écrivant une procédure à ceux qui ont gagné de performance en remplaçant les procédures par du code applicatif. Pour bien comprendre il faut garder à l’esprit les quelques points suivants qui sont parfois contradictoires :

1. Exécuter une routine stockée économise du trafic réseau car toutes les requêtes internes à la routine n’ont pas à être transmises du client au serveur.

2. Le langage est vraiment simpliste par rapport à un vrai langage de programmation rendant difficile par exemple les manipulations avancées sur les chaînes de caractères, beaucoup de constructions se révèlent très lentes

3. Exécuter des routines stockées revient à décharger le serveur d’applications et à charger le serveur de base de données, or la scalabilité de la base de données est plus difficile à assurer que celle d’un serveur d’applications

4. Elles permettent l'abstraction des règles métier pour améliorer la cohérence et la sécurité.

Enfin, les procédures stockées sont performantes s’elles sont utilisées quand c’est utile, quand on a une bonne raison de le faire. Pour un traitement long, impliquant de nombreuses requêtes et une logique simple, on peut sérieusement gagner en performance en le faisant dans une procédure stockée.

La création d’une procédure stockée :

Conclusion

 Pour conclure, ces techniques permettent déjà d’optimiser sans aucun doute la performance d’accès aux données. Toutefois, un certain nombre d’outils d’analyse et d’options de configuration conduisent également à une meilleure performance.

Ainsi, le développeur peut repérer les « goulets d’étranglement »  présent dans les requêtes et tester différentes techniques afin d’accélérer le temps d’exécution des requêtes SQL.