Après avoir parlé de l’architecture Snowflake et des différents types de tables, il reste un autre objet qu’on croise partout dans un projet data et c'est les views.

Sur le papier, une view c’est juste une table virtuelle. En pratique, Snowflake propose plusieurs types de views avec des comportements assez différents, surtout côté sécurité et performance.

1-Standard view
2-Secure view
3-Materialized view (et sa cousine la secure materialized view)

C'est quoi concrètement une view dans Snowflake ?

Une view, c’est simplement une requête SQL sauvegardée à laquelle tu donnes un nom. Au lieu d’écrire dix fois le même SELECT … JOIN … WHERE …, tu le mets dans une view et tu l'interroges aprés comme si c’était une table, par exemple depuis les dashboards BI (Qlik Sense, Power BI etc..)

Pour les standard views, Snowflake ne stocke pas le résultat de la requête et donc à chaque fois que tu fais un SELECT dessus, le moteur ré-exécute la définition de la view sur les tables sous-jacentes.

Les views dans snowflake servent surtout à :

=> Simplifier et factoriser les requêtes SQL
=> Sécuriser et partager la donnée (avec les secure views) sans exposer les tables physiques ni toute la logique interne
=> Accélérer certaines requêtes lourdes et répétitives grâce aux materialized views.

Standard view

C’est le type de view par défaut.

CREATE OR REPLACE VIEW v_sales AS
SELECT
  sale_id,
  sale_date::date      AS sale_date,
  amount::number(10,2) AS amount,
  customer_id
FROM raw_sales
WHERE status = 'OK';

Quand tu exécutes :

SELECT * FROM v_sales WHERE sale_date >= '2025-01-01';

Snowflake réécrit la requête pour aller taper directement dans raw_sales avec les bons filtres. Les données ne sont pas stockées dans la view et donc il n’y a pas d’espace disque dédié, pas de coût de maintenance spécifique.

Secure view

Les secure views sont là pour les cas où la confidentialité est importante (données personnelles, partage de données à des clients, etc....)

Techniquement, tu les crées comme une view classique, mais avec le mot-clé SECURE :

CREATE OR REPLACE SECURE VIEW v_customers_public AS
SELECT
  customer_id,
  country,
  signup_date
FROM customers;

Les différences importantes :

  • La définition de la view (le SQL derrière) n’est visible que pour les rôles autorisés.
  • C’est ce type de view que Snowflake pousse pour le data sharing sécurisé : tu peux partager une secure view sans exposer tes tables internes.
  • Le moteur désactive certaines optimisations agressives pour éviter toute fuite d’info indirecte, ce qui peut avoir un léger impact sur les perfs dans certains scénarios.


Si tu manipules de la donnée sensible, ou que tu exposes des données à l’extérieur de ton compte Snowflake, il faut partir sur une secure view plutôt qu’une standard.

Materialized view

Les materialized views sont pensées pour la performance.

L’idée : au lieu de recalculer le résultat de la requête à chaque fois, Snowflake pré-calcule et stocke le résultat sous forme physique, puis le tient à jour automatiquement en background.

Exemple :

CREATE OR REPLACE MATERIALIZED VIEW mv_sales_last_30d AS
SELECT
  customer_id,
  COUNT(*)         AS nb_orders,
  SUM(amount)      AS total_amount
FROM sales
WHERE sale_date >= DATEADD(day, -30, CURRENT_DATE)
GROUP BY customer_id;

Quand tu interroges mv_sales_last_30d, Snowflake lit les données pré-calculées au lieu de tout refaire depuis sales. C’est intéressant quand :

  • ta requête est lourde (aggrégations, grosses jointures),
  • et qu’elle est appelée souvent (dashboards, rapports quotidiens etc....).

Évidemment, il y a un revers :

  • La vue doit être maintenue dès que le tableau source bouge → ça consomme des crédits en plus.
  • Snowflake impose quelques limitations sur ce que tu peux mettre dans une materialized view (pas n’importe quelle fonction, pas de SELECT * dynamique, etc.).

Si tu veux combiner sécurité et perf, tu peux aussi créer une secure materialized view :

CREATE OR REPLACE SECURE MATERIALIZED VIEW mv_secure_sales AS
SELECT ...
FROM ...

C’est juste une materialized view + l'option sécurité d’une secure view.

Standard vs Secure vs Materialized ?

Perso, ma règle est simple : standard view par défaut, secure view dès qu’il y a de la donnée sensible ou exposée, et si un dashboard flingue mon warehouse avec toujours la même requête, je regarde si une materialized view ne serait pas plus adaptée.