# schema.yml reading a view as a source

**URL:** <https://discourse.getdbt.com/t/schema-yml-reading-a-view-as-a-source/5579>\
**Category:** Help\
**Tags:** best-practice\
**Created:** [December 13, 2022, 1:30am UTC](https://discourse.getdbt.com/t/schema-yml-reading-a-view-as-a-source/5579 "2022-12-13T01:30:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![lbert](https://avatars.discourse-cdn.com/v4/letter/l/d2c977/32.png) [@lbert](https://discourse.getdbt.com/u/lbert)\
**Post date:** [December 13, 2022, 1:30am UTC](https://discourse.getdbt.com/t/schema-yml-reading-a-view-as-a-source/5579/1 "2022-12-13T01:30:38Z")

</div>

For the yml file, are sources **view** type that can be used as a source? Our source systems have logical views, and we don’t want to duplicate the complex logic in dbt schema.yml to avoid sync issues. It seems that yml doesn’t have a views type option.

Models are materializing as a view, so it compiles a nested view reading a view or CTA reading a view. Hence, it produces an unnecessary nested view redundancy. Is there another better practice?

Thanks,  
Laura B

Sample schema.yml

```yaml
sources:
  - name: table label
    schema: schema name
    tables:
      - name: database table name

```

---

<div class="post-metadata">

**Author:** ![joellabes](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/joellabes/32/3980_2.png) [@joellabes](https://discourse.getdbt.com/u/joellabes)\
**Post date:** [December 13, 2022, 9:08pm UTC](https://discourse.getdbt.com/t/schema-yml-reading-a-view-as-a-source/5579/2 "2022-12-13T21:08:05Z")

</div>

Welcome @lbert!

> [@lbert](#):
>
> Our source systems have logical views

Does this mean you are building your dbt project inside of the same production database where the data is created, as opposed to using an ETL tool to move the data into a separate analytics warehouse?

> [@lbert](#):
>
> we don’t want to duplicate the complex logic in dbt schema.yml to avoid sync issues

Can you give an example of what you mean here? There won’t be any complex transformation logic in a yaml file, and there is no yaml in a view definition so I don’t understand what logic you’re worried about duplicating.

> [@lbert](#):
>
> Models are materializing as a view, so it compiles a nested view reading a view or CTA reading a view. Hence, it produces an unnecessary nested view redundancy. Is there another better practice?

In the dbt paradigm, it’s extremely common to have a stack of views reading from one another, as this enables you to break up your modelling logic into individual steps. Taken to an extreme this results in performance issues, so we [recommend](https://github.com/dbt-labs/dbt-project-evaluator#chained-view-dependencies) limiting the number of views chained together without a table along the way, but otherwise this isn’t an antipattern or something you need to worry too much about.

---

<div class="post-metadata">

**Author:** ![lbert](https://avatars.discourse-cdn.com/v4/letter/l/d2c977/32.png) [@lbert](https://discourse.getdbt.com/u/lbert)\
**Post date:** [December 14, 2022, 4:44pm UTC](https://discourse.getdbt.com/t/schema-yml-reading-a-view-as-a-source/5579/3 "2022-12-14T16:44:58Z")

</div>

Thank you for your response. There is a table\_type option. The data provider owns the source view, and it contains business logic. DBT project can read a view vs creating a model that uses view and then creates a view of view.

scheme.yml  
sources:

- name: bi  
schema: bi  
tables:
  - name: fact\_email\_funnel  
identifier: fact\_email\_funnel  
table\_type: table  
description: email campaign engagement metrics
  - name: fact\_clickstream  
identifier: fact\_clickstream  
**table\_type: view**  
description: web clickstream events

---

<div class="post-metadata">

**Author:** ![joellabes](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/joellabes/32/3980_2.png) [@joellabes](https://discourse.getdbt.com/u/joellabes)\
**Post date:** [December 15, 2022, 1:40am UTC](https://discourse.getdbt.com/t/schema-yml-reading-a-view-as-a-source/5579/4 "2022-12-15T01:40:20Z")

</div>

> [@lbert](#):
>
> There is a table\_type option

Can you link me to the dbt documentation where you found this setting? I don’t see it in the [source properties documentation](https://docs.getdbt.com/reference/source-properties) and have never heard of it.

> [@lbert](#):
>
> dbt project can read a view vs creating a model that uses view and then creates a view of view.

Regardless, you can query sources that are views if you want to. Our modelling best practice strongly recommends using a staging layer to ensure that you only directly access sources once (and then build other models on top of the staging layer), but you can query them directly if you want to remove a layer of abstraction.

If you choose to go down that path, keep in mind that dbt projects pretty much always have views stacked on top of each other. It’s not clear to me why it’s important to you that the source not be a view on top of a view, when your downstream models are very very likely to be views on top of views anyway.

---

<div class="post-metadata">

**Author:** ![lbert](https://avatars.discourse-cdn.com/v4/letter/l/d2c977/32.png) [@lbert](https://discourse.getdbt.com/u/lbert)\
**Post date:** [December 15, 2022, 6:55pm UTC](https://discourse.getdbt.com/t/schema-yml-reading-a-view-as-a-source/5579/5 "2022-12-15T18:55:08Z")

</div>

I understand that one of DBT mainframe work is stacked views. In the past, we have seen performance issue with nested views. Sometimes phyical tables are the best options.

The great benefit of views is having business logic can be change quickly with litle impact and quick turnaround for the stackholders and little backfill efforts.