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' (
  'id_livre' char(17) NOT NULL,
  'auteur' char(50) default NULL,
  PRIMARY KEY  ('id_livre')
);

Les requêtes, du coté de l’application, sont les suivantes:

SELECT id_livre FROM livre;
SELECT auteur FROM livre;
SELECT * FROM livre;

De cette structure où je ne peux gérer que des livres, j’en crée une autre qui m’offre plus de souplesse, la table produit:

CREATE TABLE 'produit' (
  'id_produit' mediumint(9) NOT NULL auto_increment,
  'isbn' char(17) default NULL,
  'auteur' char(50) default NULL,
  PRIMARY KEY  ('id_produit'),
  UNIQUE KEY 'isbn' ('isbn')
);

Les seuls produits disponible sont mes livres, je remplis donc ma table produit avec le contenu de la table livre :

INSERT INTO produit (isbn, auteur) SELECT id_livre, auteur FROM livre;

La dernière phase consiste à créer la vue « livre », il me faut donc au préalable effacer la table du même nom. Les vues et les tables partageant le même espace de nom.

DROP TABLE livre;

CREATE VIEW livre AS SELECT isbn AS id_livre, auteur FROM produit;

Les changements sont transparents pour les trois requêtes de mon application.

Conclusion

Voici un petit tour d’horizon sur les vues, qui nous l’espérons aura contribué à affiner votre vision sur ce sujet. Il est certain que ces tables virtuelles amènent une certaine souplesse au schéma et il serait dommage de ne pas en profiter. Cependant, ce n’est pas non plus une solution miracle, car ajouter des objets peut rapidement rendre le schéma complexe. Maintenant à vous de voir dans quels cas les vues pourrons vous être utiles. Pour nous, c’est tout… vu.

MySQL 5 : Les vues — (part 1/7)

Tags: exemples vues, MySQL, MySQL 5, vue

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 devise (
  devise enum('Euro', 'Dollar', 'Livre') NOT NULL,
  valeur decimal(6,5) default NULL,
  PRIMARY KEY  (devise)
);

INSERT INTO devise VALUES ('Livre',0.66017);
INSERT INTO devise VALUES ('Dollar',1.29852);
INSERT INTO devise VALUES ('Euro',1);

CREATE TABLE tva (
  pays enum('France', 'Royaume-Uni') NOT NULL,
  normal decimal(3,1) default NULL,
  reduit decimal(3,1) default NULL,
  PRIMARY KEY  (pays)
);

INSERT INTO tva VALUES ('Royaume-Uni',17.5,5.0);
INSERT INTO tva VALUES ('France',19.6,5.5);

Le besoin est le suivant : disposer simplement des prix TTC pour chaque pays.

On va donc créer deux vues par pays qui nous permettrons de disposer des prix TTC en fonction de la devise.

La vue produit_france, contient les produits, le prix TTC et le prix TTC réduit qui correspond à l’ajout de la TVA réduite. Les prix sont en euros.

Vue produit_france :

CREATE VIEW 'produit_france' AS
SELECT 'produit'.'id_produit' AS 'produit',
round((((('produit'.'prix_ht' * 'tva'.'normal') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'Prix_ttc_€',
round((((('produit'.'prix_ht'* 'tva'.'reduit') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'Prix_ttc_reduit_€'
FROM (('produit' join 'tva') join 'devise')
WHERE (('tva'.'pays' = 'France') and ('devise'.'devise' = 'Euro'));

Certains clients préférant la monnaie de l’oncle Sam, une deuxième vue, produit_france_dollar, est nécessaire pour avoir les prix en dollar.

Vue produit_france_dollar:

CREATE VIEW 'produit_france_dollar' AS
SELECT 'produit'.'id_produit' AS 'produit',
round((((('produit'.'prix_ht' * 'tva'.'normal') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'Prix_ttc_$',
round((((('produit'.'prix_ht'* 'tva'.'reduit') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'Prix_ttc_reduit_$'
FROM (('produit' join 'tva') join 'devise')
WHERE (('tva'.'pays' = 'France') and ('devise'.'devise' = 'Dollar'));

Même principe pour le Royaume-Uni :

CREATE VIEW 'produit_royaume_uni' AS
SELECT 'produit'.'id_produit' AS 'produit',
round((((('produit'.'prix_ht' * 'tva'.'normal') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'Net_price_£',
round((((('produit'.'prix_ht'* 'tva'.'reduit') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'reduced_ Net_price_£'
FROM (('produit' join 'tva') join 'devise')
WHERE (('tva'.'pays' = 'Royaume-Uni') and ('devise'.'devise' = 'Livre'));

Avec les prix en dollar :

CREATE VIEW 'produit_royaume_uni_dollar' AS
SELECT 'produit'.'id_produit' AS 'produit',
round((((('produit'.'prix_ht' * 'tva'.'normal') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'Net_price_$',
round((((('produit'.'prix_ht'* 'tva'.'reduit') / 100) + 'produit'.'prix_ht')
     * 'devise'.'valeur'),2) AS 'reduced_ Net_price_$'
FROM (('produit' join 'tva') join 'devise')

WHERE (('tva'.'pays' = 'Royaume-Uni') and ('devise'.'devise' = 'Dollar'));

(à suivre… Conserver la structure d’une table)

Tags: exemples vues, MySQL, MySQL 5, vue

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. TEMPTABLE a la particularité de rendre la vue non modifiable, mais cela ne gêne pas du tout, car la vue n’est accédée qu’en lecture.

Extrait de la vue « moteur de recherche »:

CREATE ALGORITHM = TEMPTABLE
VIEW moteur_de_recherche
AS
SELECT
   s.product_name as nom_produit,
   ... (les champs nécessaires)
FROM product s
 LEFT JOIN product_files sf ON s.product_id=sf.file_product_id
 LEFT JOIN ..... (toutes les tables impliquées)
WHERE ... ;

Cette astuce permet de « simplifier » de façon assez significative le schéma.

Un dernier mot pour noter que cette solution ne permet pas d’améliorer les performances de la recherche, dans le sens où la requête qui génère la vue est lancée à chaque appel de cette dernière.

(à suivre… Modifier automatiquement des données sélectionnées)

Tags: MySQL, MySQL 5, vue

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) NOT NULL,
  PRIMARY KEY  (`id_employe`)
) ;

Toutes les informations présentes dans cette table ne sont pas pertinentes pour les trois types d’utilisateurs suivant: le comptable, la secrétaire pour Paris et la secrétaire pour le reste de la France.

Une solution est donc de créer une vue par type.

Pour le comptable, il faut avoir accès aux champs nom, prénom, téléphone du bureau, statut et salaire de chaque employée. On fait donc un partitionnement vertical de la table employe. La vue correspondante est la suivante :

CREATE ALGORITHM=MERGE  SQL SECURITY DEFINER VIEW `v_comptable` AS
SELECT nom, prenom, tel_bureau, statut, salaire FROM employe;

Le profil « secrétaire pour Paris », n’a pas besoin de l’identifiant et il ne doit surtout pas avoir accès aux salaires, cette information étant confidentielle. Autre restriction, ce profil ne gère que les employées de la filiale de Paris. Le partitionnement est vertical et horizontal.

CREATE ALGORITHM= MERGE SQL SECURITY DEFINER VIEW `v_secretaire_paris` AS
SELECT nom, prenom, tel_perso, tel_bureau, statut FROM employe
WHERE ville = 'Paris';

Notre troisième vue est très proche de la deuxième. La seule différence vient du fait que là, on veut les employés qui ne travaillent pas à Paris.

CREATE ALGORITHM= MERGE SQL SECURITY DEFINER VIEW `v_secretaire_autre` AS
SELECT nom, prenom, tel_perso, tel_bureau, statut FROM employe
WHERE ville <> 'Paris';

(à suivre… Masquer la complexité du schéma)

Tags: MySQL, MySQL 5, vue

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.

Exemple:

mysql> CREATE VIEW ma_vue AS SELECT 'première valeur';
Query OK, 0 rows affected (0.24 sec)

mysql> desc ma_vue;
+-----------------+-------------+------+-----+---------+-------+
| Field           | Type        | Null | Key | Default | Extra |
+-----------------+-------------+------+-----+---------+-------+
| première valeur | varchar(15) | NO   |     |         |       |
+-----------------+-------------+------+-----+---------+-------+
1 row in set (0.50 sec)

mysql> PREPARE req_prepare FROM 'SELECT * FROM ma_vue';
Query OK, 0 rows affected (0.00 sec)
Statement prepared

mysql> EXECUTE req_prepare;
+-----------------+
| première valeur |
+-----------------+
| première valeur |
+-----------------+
1 row in set (0.01 sec)

ALTER VIEW ma_vue AS SELECT 'deuxième valeur';
Query OK, 0 rows affected (0.05 sec)

mysql> desc ma_vue;
+-----------------+-------------+------+-----+---------+-------+
| Field           | Type        | Null | Key | Default | Extra |
+-----------------+-------------+------+-----+---------+-------+
| deuxième valeur | varchar(15) | NO   |     |         |       |
+-----------------+-------------+------+-----+---------+-------+
1 row in set (0.00 sec)

mysql> EXECUTE req_prepare;
+-----------------+
| première valeur |
+-----------------+
| première valeur |
+-----------------+
1 row in set (0.00 sec)

Il faut en fait recréer la requête préparée :

mysql> DEALLOCATE PREPARE req_prepare;
Query OK, 0 rows affected (0.00 sec)

mysql> PREPARE req_prepare FROM 'SELECT * FROM ma_vue';
Query OK, 0 rows affected (0.00 sec)
Statement prepared

mysql> EXECUTE req_prepare;
+-----------------+
| deuxième valeur |
+-----------------+
| deuxième valeur |
+-----------------+
1 row in set (0.00 sec)

(à suivre… utiliser les vues)

Tags: MySQL 5, prepare statement, vue

(<- précédent)

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 name
FOR EACH ROW
triggered SQL statement

Le premier élément entrant en compte est le nom (trigger_nom). L’action qui est déclenchée l’est à la suite d’un évènement (ex : insertion d’un nouvel enregistrement dans une table). Le second paramètre (BEFORE ou AFTER) indique si le déclencheur doit être lancé avant ou après l’évènement.

Les déclencheurs peuvent être activé durant l’appel à un INSERT, un UPDATE ou un DELETE.

CREATE TRIGGER trig_livre
BEFORE INSERT

Le déclencheur est lié à une table que nous définissons avec le mot clef ON :

CREATE TRIGGER trig_livre
BEFORE INSERT
ON livre

On définit alors les instructions à effectuer une fois le déclencheur activé.

CREATE TRIGGER trig_livre
  BEFORE INSERT
  ON livre
  FOR EACH ROW
  BEGIN
     INST1;
     INST2;
  END;

Prenons un cas pratique :

mysql> CREATE TABLE account (acct_num INT, amount DECIMAL(10,2));
mysql> CREATE TRIGGER ins_sum BEFORE INSERT ON account
    -> FOR EACH ROW SET @sum = @sum + NEW.amount;

Limitation des déclencheurs liées à la version 5.0

Comme nous l’avons indiqué plus amont le support des déclencheurs est un plus dans la version 5.0 de MySQL : C’était prévu pour la version 5.1. Il n’en reste pas moins que c’est une version light qui souffre à ce jour de quelques limitations :

• On ne peut associer un déclencheur à une vue ou à une table temporaire,

• Les déclencheurs ne peuvent pas non plus faire appel à une procédure stockée ou à des fonctions.

INFORMATION_SCHEMA

La base INFORMATION_SCHEMA, standard du SQL:2003, fournit un accès aux métadonnées du serveur MySQL.

Les métadonnées sont les informations sur les données, telles que le nom des bases de données, le nom des tables, le type des données, d’index, les droits d’accès, etc.

INFORMATION_SCHEMA est une base de données virtuelle, vous ne pouvez y accéder qu’en lecture. En effet, les tables qui la composent, ne sont en fait que des vues. Vous ne verrez donc pas sur le disque dur de fichiers associés.

Par exemple, pour récupérer le code
des procédures stockées, de la base de données FRESHDAZ,  il faut
pour cela, sélectionner les colonnes ROUTINE_NAME et
ROUTINE_DEFINITION de la table  information_schema.ROUTINES:

mysql> SELECT R.ROUTINE_NAME, R.ROUTINE_DEFINITION
-> FROM information_schema.ROUTINES R
-> WHERE R.ROUTINE_TYPE = ‘PROCEDURE’ AND R.ROUTINE_SCHEMA = ‘FRESHDAZ’;

Goodies and co

Amélioration des traitements mathématiques

Avec MySQL 4.1 le résultat de la commande SELECT .01 * .01 renvoyait 0. MySQL 5 utilise une bibliothèque permettant des calculs plus précis. Ainsi 0.0001 est traité comme une valeur exacte et non plus comme une valeur approximative.

Nouveau moteur de stockage

Un nouveau moteur de stockage a été ajouté depuis MySQL 5.0.3 : FEDERATED Storage Engine. Il permet d’accéder à des données présentes sur des bases de données distantes.

Conclusion

MySQL 5 apporte un réel confort en terme de fonctionnalités par rapport à ses versions antérieures. Les déclencheurs, les vues et les procédures stockées propulsent MySQL dans le monde des SGBD matures et permet de soutenir la comparaison avec Oracle, PostgreSQL et autres.

Avec cette nouvelle version MySQL élargit son public en ne s’adressent plus principalement aux architectes d’applications Web mais à tous les développeurs.

Tags: déclencheur, information_schema, MySQL, MySQL 5, sgbd, trigger

(<- précédent)

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 données sont effectuées via des procédures stockées.

Des procédures stockées pour centraliser les requêtes

Différentes applications peuvent accéder à la même base de données et avoir les mêmes fonctionnalités. Les procédures stockées peuvent alors servir à factoriser ce code SQL commun ce qui permet de diminuer la redondance et facilite la maintenance du code.

Des procédures stockées pour augmenter les performances

Les commandes n’ont pas à être analysées plusieurs fois, elles sont (pré)compilées sur le serveur et bien moins d’informations transitent sur le réseau, le trafic y est donc limité.

Les procédures stockées sont particulièrement utiles quand les clients qui accèdent à la base de données ne sont pas sur le même serveur.

Le principal inconvénient des procédures stockées, et qu’elles nous rendent complètement dépendantes de l’éditeur de la base de données, puisqu’il n’existe pas de langage universel de développement de procédures stockées.

Une migration simplifiée par le respect du standard SQL 2003

Les procédures stockées de MySQL 5 respectent certaines recommandations du standard SQL 2003. La syntaxe est donc très proche de la syntaxe de DB2 ce qui permet une migration facile entre les deux outils. La migration en provenance d’Oracle ou de MS SQL Server impliquera plus de travail manuel étant donné que leurs bases de données ne respectent pas autant le standard.

Astuce : Pour migrer d’Oracle vers MySQL on peut utiliser les outils de migration Oracle vers DB2 puis passer de DB2 à MySQL qui sont très proches.

Syntaxe

CREATE
[DEFINER = { user | CURRENT_USER }]
PROCEDURE sp_name([parametres])
    LANGUAGE SQL
  | [NOT] DETERMINISTIC
  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
  | SQL SECURITY { DEFINER | INVOKER }
  | COMMENT 'string'
routines

(suite ->)

Tags: MySQL, MySQL 5, procédure stockées, routines, sgbd

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 elle ne force plus un découpage de table pour gérer la confidentialité et les droits donnés aux utilisateurs. Les vues permettront de remplir ce rôle.

Les vues compliquent les mises à jour

Insérer ou modifier des données dans une vue n’est pas aussi simple que de faire un update dans une table. Pour pouvoir le faire il faut réfléchir de façon plus poussée au modèle conceptuel de données :

Une vue n’est pas forcément accessible en insertion / modification. Pour cela il faut qu’il n’y ait pas d’incompatibilité logique à ce qu’elle le soit.

• Tous les champs des tables possédant des contraintes d’intégrités (index unique, clés primaires ..) doivent être présent

• La vue ne doit pas posséder de regroupement ou d’exclusion ( GROUP BY , DISTINCT, UNION)

• Le plan d’exécution de la vue ne doit pas passer par une table temporaire

Les vues de MySQL 5 par la pratique

CREATE
[OR REPLACE]
VIEW view-name
[(column-list)]
AS select-statement

Créer une vue revient à appliquer un filtre à une ou plusieurs tables. Pour schématiser prenons une entreprise normale. Dans celle-ci il y a des employés regroupés sous le terme ‘personnel’. On regroupe ces employés par ‘catégorie’ en fonction de leur activité (administratif, informatique, commercial,…).

On peut créer une vue contenant l’ensemble des informaticiens avec le code suivant :

CREATE VIEW personnelinformatique

AS SELECT a.nom AS nom,a.prenom AS prenom,b.service AS service

from categorie b, personnel a

where a.fkCategorie = 1 and a.fkCategorie = b.pkCategorie;

Optimisation des vues de MySQL 5

CREATE

[ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]

[DEFINER = { user | CURRENT_USER }]

[SQL SECURITY { DEFINER | INVOKER }]

VIEW view-name

[(column-list)]

AS select-statement

[WITH [CASCADED | LOCAL] CHECK OPTION]

• La clause facultative «ALGORITHM» n’est pas standard. Elle permet d’optimiser votre code.

• MERGE utilise la requête SQL ayant servie à la création de la vue comme base d’opération.

• TEMPTABLE utilise une table temporaire créée pour stocker les résultats.

Par défaut l’optimiseur MySQL décide lui-même quelle option choisir (UNDEFINED). Pour améliorer les performances, il est généralement plus intéressant de le définir statiquement afin d’éviter à l’optimiseur de le découvrir à chaque exécution.

«DEFINER» assigne un créateur à la vue.

«SQL SECURITY» définit quelles seront les droits de l’utilisateur, lors de l’exécution de la vue. Deux valeurs sont possibles:

- DEFINER permet d’exécuter la vue avec les droits du créateur.

- INVOKER permet d’exécuter la vue avec ses propres droits.

Pour finir, la clause facultative CHECK OPTION permet de ne modifier que la vue ou du moins des informations qui respectent les contraintes de la vue. Ainsi dans notre exemple, avec la clause CHECK OPTION, il ne sera pas possible de modifier au travers de la vue « personnelInformatique » une personne ne travaillant pas dans le service informatique.

Manque

Le seul léger bémol est que la version 5.0 de MySQL ne disposera pas des vues matérialisées. Les vues matérialisées sont des données physiquement dupliquées dans le SGDB. Par exemple le résultat d’un calcul n’est plus à refaire pour chaque accès. Leur utilité se fait particulièrement sentir lors de traitements de tables très volumineuses .

Comparaison avec d’autres SGBD

Possibilité des vues avec MySQL 5.0

UPDATEABLE_KEY est une fonctionnalité de MySQL permettant de modifier une clef primaire par le biais d’une vue.

Tags: MySQL, MySQL 5, sgbd, vues