(<- 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 …