13-02-2016, 12:36 PM
Ouep, c'est le premier avantage Salty (qui devient magique quand on a plusieurs clients utilisant la même BDD). C'est un avantage qu'on retrouve dans les procédures stockées également (qui permettent de faire plus qu'un simple SELECT: une vue ne fera jamais qu'un seul SELECT alors qu'une procédure peut faire un ou plusieurs INSERT/UPDATE/DELETE/CREATE/SELECT).
L'autre atout est d'avoir des colonnes calculées tout en ayant une BDD normalisée: si une colonne est calculable à partir des données d'une autre (genre l'exemple de ce topic), alors la vue te permet de le faire sans dénormaliser la BDD alors qu'une table créerait une colonne redondante qui ne serait jamais à jour. D'ailleurs, la vue étant calculée à la volée, cela économise la place de ces colonnes calculées sur le disque (là, on retrouve l'avantage des colonnes virtuelles du MySQL 5.7).
La vue pourrait aussi masquer la complexité d'un stockage. Par exemple, on pourrait stocker toutes les positions des objets du jeu dans une seule table (id, x, y) et utiliser une clef étrangère dans les différentes tables du jeu (la table "arme" possède une colonne idPosition, la table "case" aussi, etc). La vue se chargerait de la jointure automatique. Cela permet de ne pas se taper la jointure à la main (parce qu'on aura besoin de l'info de position dans 90% des cas). La vue peut même masquer cette jointure (au lieu d'avoir arme::nom|idPosition+position::x|y|y la vue renverrait vueArme::nom|x|y|z masquant ainsi le fait que ces données sont stockées sur deux tables).
L'autre atout est d'avoir des colonnes calculées tout en ayant une BDD normalisée: si une colonne est calculable à partir des données d'une autre (genre l'exemple de ce topic), alors la vue te permet de le faire sans dénormaliser la BDD alors qu'une table créerait une colonne redondante qui ne serait jamais à jour. D'ailleurs, la vue étant calculée à la volée, cela économise la place de ces colonnes calculées sur le disque (là, on retrouve l'avantage des colonnes virtuelles du MySQL 5.7).
La vue pourrait aussi masquer la complexité d'un stockage. Par exemple, on pourrait stocker toutes les positions des objets du jeu dans une seule table (id, x, y) et utiliser une clef étrangère dans les différentes tables du jeu (la table "arme" possède une colonne idPosition, la table "case" aussi, etc). La vue se chargerait de la jointure automatique. Cela permet de ne pas se taper la jointure à la main (parce qu'on aura besoin de l'info de position dans 90% des cas). La vue peut même masquer cette jointure (au lieu d'avoir arme::nom|idPosition+position::x|y|y la vue renverrait vueArme::nom|x|y|z masquant ainsi le fait que ces données sont stockées sur deux tables).