Discussion :

[Invité]

Je sais qu'on peut sélectionner et c'est pour cela que je les utilise, mais peut-on faire un INSERT ? un DELETE ?

[Médiat]

Oui, sous certaines conditions (dont je ne serais pas étonné qu'elles dépendent du SGBDR).
Par exemple pour une vue comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT IdClient, SUM(Montant) AS Total
FROM Client c INNER JOIN Facture f USING (IdClient)
GROUP BY IdClient

on voit mal ce que pourrait vouloir dire un INSERT ou un DELETE.

Alors que pour la Vue

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT IdClient
FROM Client
WHERE Departement = '75'

on voit bien ce que pourrait être un DELETE, par contre un INSERT n'est sans doute pas possible (il y a sans doute des colonnes NOT NULL autre que IdClient dans la table Client)

[Invité]

Heu comment dire...bon c'est MS-SQL Server, mais le mécanisme de la vue, je ne le comprends pas très bien. J'imaginais que c'était une sélection de données, sur laquelle je pouvais "requetter".
Si j'insère dans la vue : ça insère dans la base ?

<edit : message édité donc réponse à la question qui se trouvait là>

[Médiat]

Si j'insère dans la vue : ça insère dans la base ?

Oui, sous certaines conditions, regarde la doc de MS SqlServer et la syntaxe du CREATE VIEW, tu devrais y trouver les fameuses conditions...

[SQLpro]

Sur les INSERT / UPDATE / DELETE dans les vues, la norme précise que :

*** Etrait de mon livre SQL Synthex ***
"
3.7.1 Mise à jour des données à travers les vues
Comme lorsqu'il s'agit d'une table, on peut mettre à jour les données des vues (insertion, suppression, modification), mais à condition que certaines règles soient respectées :
• ne porter que sur un ensemble de tables ou de vues modifiables (pas de sous requête sauf dans la clause WHERE, ni de requête ensembliste EXCEPT ou INTERSECT). Les vues contenant des tables jointes ou l'opérateur ensembliste UNION ALL peuvent être mise à jour dans certains cas;
• ne pas contenir de dédoublonnage (pas de mot clef DISTINCT) ;
• ne pas contenir de données transformées (pas de concaténation, addition de colonne, fonction...);
• ne pas contenir de clause de groupage ou de calcul d'agrégat (pas de clause GROUP BY, HAVING, ni de fonction COUNT, SUM, AVG, MIN, MAX);
Cependant, et comme l'indique la première condition, une vue peut porter sur une autre vue et pour que la nouvelle vue construite à partir d'une autre vue puisse être modifiée, il faut qu'à chaque niveau d'imbrication des vues l'ensemble de ces règles soient respectées.

Les contraintes de la table étant respectées lors des mises à jour de vue, on ne peut insérer des données à travers une vue que si ces dernières respectent les contraintes. En particulier une vue qui ne contiendrait pas une colonne rendue obligatoire par une contrainte NOT NULL ne pourrait faire l'objet d'une insertion, alors qu'elle peut faire l'objet d'une modification ou d'une suppression de ligne.

En fait on peut dire que seules les vues encapsulant un sous ensemble des lignes d'une unique table peuvent être mises à jour.

"

A +

[orafrance]

A noter que certains SGBD comme Oracle et SQL Server (si je ne m'abuse ) permettent de coder des triggers sur la vue pour pouvoir ventiler les mises à jour dans les tables utilisées par la vue

Néanmoins, je n'apprécie pas l'utilisation de tels triggers

[Invité]

A noter que certains SGBD comme Oracle et SQL Server (si je ne m'abuse) permettent de coder des triggers sur la vue pour pouvoir ventiler les mises à jour dans les tables utilisées par la vue

Là ça me dépasse

[Fabien Celaia]

A noter que certains SGBD comme Oracle et SQL Server (si je ne m'abuse ) permettent de coder des triggers sur la vue pour pouvoir ventiler les mises à jour dans les tables utilisées par la vue

Néanmoins, je n'apprécie pas l'utilisation de tels triggers

Pour MS, c'est bien spécifié dans la doc, mais en pratique, je n'en ai jamais vu ET le create trigger sur vue semble planter !

[orafrance]

A noter que certains SGBD comme Oracle et SQL Server (si je ne m'abuse) permettent de coder des triggers sur la vue pour pouvoir ventiler les mises à jour dans les tables utilisées par la vue

Là ça me dépasse

Une vue exécute une requête donc tu as une vue éventuellement de plusieurs tables. Imaginons une table employé et une table salaire avec une vue qui joint les deux pour voir le salaire de chaque employé (ne prétez pas attention à la bétise de ce modèle ). Si on veut mettre à jour en une fois le nom de l'employé et son salaire on peut être tenté de mettre à jour la vue. Mais lorsque la requête est complexe, le SGBD ne saura pas dans quel table il doit modifier le nom et laquelle modifier le salaire. Donc on crée un trigger qui va modifier les données où il faut. Ce trigger remplace l'ordre d'update envoyé à la vue.

Est-ce plus clair ?

Fadace merci pour l'info