Discussion :

[berceker united]

Bonjour,

Je suis tombé sur une cas qui m'a un peut déconcerté. Je suis dans une entreprise qui utilise des vues est des tables mais n'ayant pas de model de données et que les noms des objets n'indique pas si c'est une table ou une vue.
Dans mon script, je devais faire un insert puis des updates sur la même table. L'insert se passe bien mais la mise à jour ne se faisait pas et je ne comprenais pas surtout qu'il y a aucun message d'erreur. Ceci, jusqu'à que je me rend compte que la table en question est une vue. Personnellement, cela me viendrait jamais à l'esprit de faire un insert dans une vue. Cela m'est complètement illogique de faire ce type de requête.
Mais alors, dans quel but d'autoriser ce genre de chose ? Pourquoi il y a aucun message de retour lorsqu'on tente de faire un update ou un delete sur une vue ?

Merci

[KiLVaiDeN]

Bonjour,

Théoriquement, on ne peut pas faire d'INSERT dans une vue étant donné qu'il ne s'agit que d'une projection des données réelles. Mais, si il s'agit d'une vue matérialisée, il se peut que ce soit tout de même possible, parce que la vue matérialisée bien que renseignée par une ou plusieurs tables est un véritable enregistrement physique.

Peut-être aussi, si la vue n'est associée qu'à une seule table, le SGBD peut faire la "traduction" de ton INSERT pour que les données aillent au bon endroit. Dans le cas d'une vue qui concernerait de multiples tables en même temps, cela me parait plus compliqué par contre.

A+

[berceker united]

Merci pour votre retour. Pourtant je suis tombé sur une cas d'un vue utilisant plusieurs table sauf que les champs en sortie est issus d'une table. Dans mon cas, je ne pense pas que ça soit une vue matérialisée.
Mais je comprend vraiment pas qu'on puisse autoriser ce genre de chose. Surtout que cela peut induire un développeur en erreur.

[SQLpro]

Stupide !!!

Bonjour,

Théoriquement, on ne peut pas faire d'INSERT dans une vue étant donné qu'il ne s'agit que d'une projection des données réelles.
[...]
Peut-être aussi, si la vue n'est associée qu'à une seule table, le SGBD peut faire la "traduction" de ton INSERT pour que les données aillent au bon endroit. Dans le cas d'une vue qui concernerait de multiples tables en même temps, cela me parait plus compliqué par contre.

Avant d'affirmer n'importe quoi révisez vos cours... Une vue n'est juste qu'une forme particulière de table et peut être mise à jour sous conditions. Cela est même dans l'ADN des bases de données relationnelles. Pour information la règle de Codd n°6 (l'inventeur des bases de données relationnelles) le précise depuis 1985 ! A lire : http://sqlpro.developpez.com/SGBDR/ReglesCodd/
Ce n'est pas parce que certains pseudo SGBDR comme MySQmerde ne savaient pas le faire et que malheureusement on enseigne maintenant sur cet ersatz de SGBD non relationnel qu'il faut affirmer des conneries !
Je vous prie de revoir vos cours et lire par exemple mon livre sur SQL qui en parle à plusieurs reprises :

Notez aussi que la norme SQL ne fait pas de distinction entre les vues et les tables d'un point de vue métadonnées. En effet si vous demandez la liste des tables en lançant la requêtes de métadonnées suivantes :

Code :

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

SELECT * FROM INFORMATION_SCHEMA.TABLES

Vous y verrez les tables ET les vues. Les tabels étant des tables de type "base table" et les vues des "view"...

L'intérêt des vues est magistral et toutes les applications ne devraient travailler qu'à travers les vues. C'est ce que l'on appelle le MED ou Modele Externe de Données. Hélas rares sont les développeurs à le faire et surtout à comprendre pourquoi.

• Avantage n°1 : si une table a été ma structurée (par exemple une table obèse), le fait d'avoir attaqué l'application par des vues permet de la casser en plusieurs tables sans aucun impact sur l'application puisqu'il suffit de reconstituer la vue après éclatement de la table
• Avantage n°2 : protection des données... Par exemple une table d'employés peut comporter des données qui sont confidentielles pour certains utilisateurs et pas d'autres. La vue assure la publication correcte des données pour chacun des acteurs, par exemple RH, syndicat, médecin du travail.

Pour ce qui est de la mise à jour des vues, lisez l'article déjà cité sur les règles de CODD vous trouverez tout ce qu'il faut pour comprendre les choses....

Mais, si il s'agit d'une vue matérialisée, il se peut que ce soit tout de même possible, parce que la vue matérialisée bien que renseignée par une ou plusieurs tables est un véritable enregistrement physique.

Aussi stupide !!!

En effet une vue matérialisée (ou indexée) ne peut pas être mise à jour directement. C'est une forme de redondance qui automatise la mise à jour des données primaires des tables dans une vue qui contrairement à l’ordinaire ne stocke pas les données. Autrement dit une vue matérialisée (ou indexées dans SQL Server) stocke des données qui sont des extractions d'autres tables et sont "rafraichies" de manière automatique (vues indexées) ou manuelles (vue matérialisées).

A +

[escartefigue]

L'intérêt des vues est magistral et toutes les applications ne devraient travailler qu'à travers les vues. C'est ce que l'on appelle le MED ou Modele Externe de Données. Hélas rares sont les développeurs à le faire et surtout à comprendre pourquoi.

• Avantage n°1 : si une table a été ma structurée (par exemple une table obèse), le fait d'avoir attaqué l'application par des vues permet de la casser en plusieurs tables sans aucun impact sur l'application puisqu'il suffit de reconstituer la vue après éclatement de la table
• Avantage n°2 : protection des données... Par exemple une table d'employés peut comporter des données qui sont confidentielles pour certains utilisateurs et pas d'autres. La vue assure la publication correcte des données pour chacun des acteurs, par exemple RH, syndicat, médecin du travail.

Et avantage n°3 : l'utilisation d'une vue permet de ne pas impacter les traitements lors d'évolution des tables : le plus souvent, les nouvelles colonnes n'étant pas requises pour tous les traitements existants, mais seulement pour certains d'entre eux, on crée une nouvelle version de vue pour les traitements qui ont besoin de la nouvelle colonne, alors que les autres continuent d'utiliser la vue de version précédente (via un nommage des vue différent)
Je connais de nombreux sites où l'usage des vues est obligatoire, uniquement pour cette raison justement.

[berceker united]

On sa calme, c'est noël !

Je ne remet pas en cause le bien fondé d'une vue et je suis même 100% d'accord avec SQLPro et Escartefigue. J'avoue que j'ai été influencé par le monde MySQL car j'ai commencé par lui pour aujourd'hui avec SQL Server. J'ai gardé, à tord, cette fausse idée qu'une vue est une représentation virtuel d'une ou des tables. Et le faite qu'une vue puisse être le résultat d'une requête pouvant utiliser potentiellement plusieurs tables me semblait illogique d'y faire une opération d'écriture sur une vue, sauf à y placer des index. Dans ma tête, une vue ne pouvait être utilisé que pour consultation des données via la commande SELECT.

Sur SQL Server (2012) j'ai réalisé un simple teste consistant à créer une vue interfaçant une table sans clause. J'ai tenté d'y faire une mise à jour d'un champ sur cette vue mais il se passe rien. Est-ce que SQL Server ne fait l'opération demandée car il sait pas faire mais ne retourne pas d'alerte car c'est pas une erreur car ça répond à la règle Codd #6 ?

Sur quel SGBD est-il possible de réaliser une opération d'écriture, comment se passe t-il lorsqu'il y a plusieurs tables d'impliquer ?

[escartefigue]

Sur SQL Server (2012) j'ai réalisé un simple teste consistant à créer une vue interfaçant une table sans clause. J'ai tenté d'y faire une mise à jour d'un champ sur cette vue mais il se passe rien. Est-ce que SQL Server ne fait l'opération demandée car il sait pas faire mais ne retourne pas d'alerte car c'est pas une erreur car ça répond à la règle Codd #6 ?

Je suppose que vous voulez dire sans clause where.
Il ne se passe rien, ca n'existe pas ,
- soit vous avez un diagnostic que vous n'avez pas intercepté
- soit la requête a été exécutée avec succès
Dans le 2ème cas, soit votre valeur avant/après est identique, soit la transaction n'a pas été commitée, les modifs sont donc perdues