dasini.net – Journal d'un expert MySQL

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.

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.

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.

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

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 une requête préparée.

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

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.

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.