Why One model per source table rule in dbt? - Purpose & Use Cases

The Big Idea

What if your data models were as simple and clear as separate folders instead of one messy drawer?

The Scenario

Imagine you have a big spreadsheet with many sheets, each sheet holding different data. You try to write one giant report by mixing all sheets manually in one place. It gets confusing fast.

The Problem

Manually combining data from many tables into one model is slow and messy. It's easy to make mistakes, hard to update, and difficult to understand what each part does.

The Solution

The "One model per source table" rule means you create a simple, clear model for each source table. This keeps things organized, easy to test, and easy to update without breaking everything.

Before vs After

✗ Before

select * from sales join customers on sales.customer_id = customers.id join products on sales.product_id = products.id

✓ After

model_sales as (select * from sales), model_customers as (select * from customers), model_products as (select * from products)

What It Enables

This rule lets you build clean, reusable data models that are easy to maintain and understand, making your data projects more reliable and faster to develop.

Real Life Example

In a company, each department's data is stored in separate tables. By modeling each table separately, analysts can quickly update or fix one without affecting others, speeding up reporting.

Key Takeaways

Manual mixing of tables leads to confusion and errors.

One model per source table keeps data organized and clear.

This approach makes data projects easier to maintain and faster to build.