Paths Subjects Questions Quizzes Pricing Search
Intermediate Open Pro

Reviewing a PR That Breaks the Staging/Intermediate/Marts Layering

A teammate opens a PR adding a new model, models/staging/stg_orders_with_ltv.sql:

-- models/staging/stg_orders_with_ltv.sql
{{ config(materialized='view') }}

select
    o.id as order_id,
    o.customer_id,
    o.status as order_status,
    c.signup_date,
    sum(p.amount) over (partition by o.customer_id) as customer_ltv
from {{ source('raw_app', 'orders') }} as o
left join {{ ref('stg_customers') }} as c
    on o.customer_id = c.customer_id
left join {{ ref('stg_payments') }} as p
    on o.id = p.order_id

The PR description says: "Added a staging model that gives us orders with customer signup date and lifetime value pre-joined, so marts don't have to redo this join every time."

  1. Explain specifically what's wrong with placing this model in staging/, independent of whether the SQL itself is correct.
  2. Where should this logic actually live, and how would you restructure it, potentially into more than one model?
  3. The teammate pushes back: "it works fine and it's faster to just put everything in one folder." What's the concrete cost of that approach as the project grows past this one model?

Share this question

← Back to dbt & Analytics Engineering practice

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.