Avec les sorties de MySQL 5.5.8 et de MariaDB 5.2.4, l’écosystème SGBDR open source se retrouve donc avec 3 bases (n’oublions pas MySQL 5.1.53) en GA. J’ai eu envi de voir le résultat des améliorations apportées par les équipes  d‘Oracle sur la première version majeure post rachat (MySQL 5.5.8) et celles apportées par la communauté et les équipes de Monty program pour la version basée sur MySQL 5.1.53  (MariaDB 5.2.4).

De nombreuses optimisations ont eu lieu sur la version MySQL 5.5.8, ainsi que sur le moteur de stockage InnoDB. Idem pour MariaDB et la version InnoDB  de …

(<- précédent)

Conserver la structure d’une table si elle doit être modifiée

La problématique est de mettre à jour le schéma de l’application en changeant la structure de certaines tables.

Changer le schéma a comme principal impact d’obliger de modifier les requêtes de l’application. Il sera donc nécessaire de les identifier pour les mettre à jour à leur tour, ce qui peut rapidement devenir fastidieux. Au travers de l’exemple qui suit, nous allons créer une vue qui va masquer le changement de table ce qui nous évite de modifier les requêtes applicatives. Une nouvelle version de l’application pourra utiliser la nouvelle table sans être obligé d’utiliser la vue, on assure ainsi la compatibilité ascendante.

Ma table de départ est la table livre:

CREATE TABLE 'livre' …

(<- précédent)

Modifier automatiquement des données sélectionnées

Pour ce troisième exemple, nous allons nous intéresser au schéma (là encore très simplifié) d’une application qui permet de vendre des produits en France et au Royaume-Uni, en euro, livre et dollar. Cette application possède une table produit, qui contient le produit (son identifiant) et son prix hors taxe en euro.

Structure de la table produit:

CREATE TABLE produit (
  id_produit mediumint(8) unsigned NOT NULL auto_increment,
  prix_ht decimal(6,2) default NULL,
  PRIMARY KEY  (id_produit)
)

Nous disposons également des tables devise et tva qui gèrent respectivement le taux de change des devises et la TVA de différents pays.

Tables devise et tva:

CREATE TABLE …

(<- précédent)

Masquer la complexité du schéma

L’équipe de développement doit écrire un moteur de recherche pour une application de commerce électronique. Voici un extrait des tables de la base de données impliquées dans la recherche des produits du site.

La difficulté est de générer la bonne requête avec les bonnes jointures (plus d’une dizaine), à chaque recherche. Une solution pour faciliter le travail des développeurs est de créer une vue qui fait référence à toutes les tables impliquées dans la recherche des produits. Les recherches se feront donc sur cette vue, avec des requêtes plus simples à écrire.

La vue est créée avec l’algorithme TEMPTABLE, les verrous sur les tables sous-jacentes seront libérés plus rapidement ce qui permettra de moins pénaliser les autres requêtes. …

(<- précédent)

Utiliser les vues

Voici quelques exemples pratiques très simples pour illustrer les différents besoins auxquels peuvent répondre les vues. On aura ici, une vue administrateur de base de données. Les objets créés ne seront pas utilisés directement par les utilisateurs mais aux travers d’une application.

Contrôler l’intégrité en restreignant l’accès aux données pour améliorer la confidentialité

La table employe de mon application, contient toutes les informations sur les employées.

CREATE TABLE `employe` (
  `id_employe` int(10) unsigned NOT NULL auto_increment,
  `nom` char(45) NOT NULL,
  `prenom` char(45) NOT NULL,
  `tel_perso` char(10) NOT NULL,
  `tel_bureau` char(10) NOT NULL,
  `statut` char(45) NOT NULL,
  `ville` char(45) NOT NULL,
  `salaire` decimal(7,2) …

(<- précédent)

Restrictions

Lors de la création d’une vue, certaines contraintes doivent être prises en compte :

• Il n’est pas possible de créer un index sur une vue
• La vue ne peut pas contenir de sous-requêtes dans la clause FROM du SELECT.
• Il n’est pas possible d’utiliser de variables dans une vue.
• Les objets (tables et vues) nécessaires à la création de la vue doivent exister avant de la créer.
• Si un objet référencé par la vue est effacé, la vue n’est alors plus accessible.
• Une vue ne peut référencer une table temporaire (TEMPORARY TABLE)
• Il n’est pas possible de créer des vues temporaires.
• Il n’est pas possible d’associer un trigger à une vue.
• La définition d’une vue est “gelée” dans …

Déclencheurs

Les déclencheurs (triggers) sont des ordres de déclenchement d’opérations quand un évènement survient sur une table.

Des déclencheurs pour maintenir la cohérence des données

Ils sont souvent utilisés pour assurer la cohérence des données dans la base, en réalisant des contraintes qui doivent porter sur plusieurs tables.

Les déclencheurs combinés aux transactions permettent de créer tous les mécanismes d’intégrité référentielle. La norme SQL 3 a d’ailleurs imposé l’utilisation des déclencheurs.

Initialement prévu pour la version 5.1, l’équipe de développement à finalement profité d’une avance sur le calendrier de développement pour proposer une version simplifié des déclencheurs dans la version 5.0.

Syntaxe de base

CREATE TRIGGER trigger_nom
[DEFINER = { user | CURRENT_USER }]
{ BEFORE | AFTER }
{ INSERT | UPDATE | DELETE }
ON table …

Procédures stockées et fonctions

Les procédures stockées sont des listes de commandes qui peuvent être compilées et stockées sur le serveur. Elles permettent de déplacer une partie de la logique métier d’une application de base de données du client vers le serveur. Les clients n’ont plus besoin de soumettre à nouveau toute la commande, mais font simplement référence à la procédure stockée.

Cela se traduit par une amélioration de la sécurité, une diminution de la redondance du code, et une augmentation des performances.

Des procédures stockées pour améliorer la sécurité

Elles peuvent fournir une protection contre les attaques d’injection SQL, principalement contre celles qui utilisent un opérateur AND ou OR pour ajouter des commandes à une valeur de paramètre d’entrée valide. Les programmes clients n’accédant plus directement aux tables. Toutes les opérations de gestion des …

Vues Des vues pour faciliter la visibilité

Les vues sont la plupart du temps utiles pour donner aux utilisateurs l’accès à un ensemble de relations représentées sous la forme d’une table. Une vue est une table virtuelle ; les données de la vue sont en fait des champs de différentes tables regroupées, ou des résultats d’opérations sur ces champs.

Des vues pour améliorer la confidentialité

Une vue n’est pas forcément un regroupement de plusieurs tables mais peut être un sous ensemble d’une table (ou de plusieurs) ce qui permet de cacher des champs aux utilisateurs.

Par exemple il ne sera pas forcément utile à tout le monde d’accéder aux champs indiquant les bénéfices réalisés sur un projet dans votre base comptable. Vous pouvez donc créer une vue contenant tous les champs de la table projet sauf le champs bénéfice.

L’approche avec MySQL 5 sera donc plus souple car …