Pourquoi les vues utilisées à la place de Sql Statement

Oui, il y a beaucoup de raisons.

1. Sécurité : lorsque vous souhaitez limiter ce que certains users peuvent voir depuis une table, vous pouvez simplement autoriser l'access à la vue au lieu de la table sous-jacente.
2. Simplicité : lorsque vous avez besoin d'utiliser la requête / vue sur une sous-requête. Ou juste lorsque vous ne voulez pas taper plusieurs fois la même requête complexe encore et encore.
3. Vues matérialisées (si votre SGBDR le supporte): peut augmenter les performances sur certaines requêtes analytiques (Data-warehousing).
4. Partitionnement : si vous voulez une relation (vue) représentant juste un sous-set d'une autre relation (table). IE, vous pouvez créer vue invoices_2011 avec seulement les factures faites en 2011 à partir des invoices table.

Mettre à jour:

Sur l'exemple demandé:

Disons que vous avez cette table:

 create table customers ( customer_id integer primary key, name varchar(200) not null, dob date ); 

Et vous voulez que l'user bart ne voit que le name et le name des clients nés avant 1980. Vous ne pouvez pas accorder l'access aux customers table à bart parce qu'il pourrait voir n'importe quoi stocké dessus.

Vous créez plutôt une vue:

 create view customers_1980 as select name, dob from customers where dob < '1980-01-01'; 

Et puis accorder l'access bart à cette vue:

 grant select on customers_1980 to bart; 

De cette façon, le bart n'aura access qu'au sous-set de la vue des customers restreints.

L'utilisation de vues est appropriée lorsque vous souhaitez fournir un access restreint aux users.

Les requêtes qui sont fréquemment utilisées peuvent être créées dans des vues indexées qui peuvent vous fournir une amélioration des performances.

S'il vous plaît passer par cet article