Add note about Snowflake using Dynamic Tables instead of Materialized…

… Views (#4375)

## What are you changing in this pull request and why?
<!---
Describe your changes and why you're making them. If linked to an open
issue or a pull request on dbt Core, then link to them here! 

To learn more about the writing conventions used in the dbt Labs docs,
see the [Content style
guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md).
-->

Materialized view documentation page lacks any information that the
implementation differs for one of the major adapters: Snowflake. It is
mentioned in the Snowflake specific configs though.

So just adding a link in the Materialized View docs pointing to
Snowflake configs.

## Checklist
<!--
Uncomment if you're publishing docs for a prerelease version of dbt
(delete if not applicable):
- [ ] Add versioning components, as described in [Versioning
Docs](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#versioning-entire-pages)
- [ ] Add a note to the prerelease version [Migration
Guide](https://github.com/dbt-labs/docs.getdbt.com/tree/current/website/docs/guides/migration/versions)
-->
- [x] Review the [Content style
guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md)
and [About
versioning](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/single-sourcing-content.md#adding-a-new-version)
so my content adheres to these guidelines.
- [x] Add a checklist item for anything that needs to happen before this
PR is merged, such as "needs technical review" or "change base branch."

website/docs/docs/build/materializations.md

@@ -69,8 +69,8 @@ When using the `view` materialization, your model is rebuilt as a view on each r
 * **Pros:** No additional data is stored, views on top of source data will always have the latest records in them.
 * **Cons:** Views that perform a significant transformation, or are stacked on top of other views, are slow to query.
 * **Advice:**
-    * Generally start with views for your models, and only change to another materialization when you're noticing performance problems.
-    * Views are best suited for models that do not do significant transformation, e.g. renaming, recasting columns.
+    * Generally start with views for your models, and only change to another materialization when you notice performance problems.
+    * Views are best suited for models that do not do significant transformation, e.g. renaming, or recasting columns.
 
 ### Table
 When using the `table` materialization, your model is rebuilt as a <Term id="table" /> on each run, via a `create table as` statement.
@@ -135,14 +135,16 @@ Materialized views are a combination of a view and a table, and serve use cases
   * Materialized views operate much like incremental materializations, however they are usually
 able to be refreshed without manual interference on a regular cadence (depending on the database), forgoing the regular dbt batch refresh
 required with incremental materializations
-  * `dbt run` on materialized views correspond to a code deployment, just like views
+  * `dbt run` on materialized views corresponds to a code deployment, just like views
 * **Cons:**
   * Due to the fact that materialized views are more complex database objects, database platforms tend to have
 less configuration options available, see your database platform's docs for more details
   * Materialized views may not be supported by every database platform
 * **Advice:**
   * Consider materialized views for use cases where incremental models are sufficient, but you would like the data platform to manage the incremental logic and refresh.
 
+**Note:** `dbt-snowflake` _does not_ support materialized views, it uses Dynamic Tables instead. For details, refer to [Snowflake specific configurations](/reference/resource-configs/snowflake-configs#dynamic-tables).
+
 ## Python materializations
 
 Python models support two materializations: