Why Business Logic in SQL Breaks Down

The Business Logic in SQL Problem

Encode a business rule into a SQL view and the rule lives in exactly one place. Every other system that needs it — the dbt model, the Python job, the dashboard, the agent — rediscovers it and writes its own copy, and the copies drift.

The Problem

SQL isn't a business rules engine. When you encode logic directly into transformations, you're storing critical business knowledge in code that only runs in one place. This leads to the same problems that cause static pipelines to break when business rules change.

-- Active users with embedded logic
CREATE VIEW active_users_by_region AS
SELECT
  region,
  COUNT(DISTINCT CASE
    WHEN account_status != 'canceled'
    AND last_login > CURRENT_DATE - 30
    AND is_test_account = false
    THEN user_id
  END) as active_users
FROM users
GROUP BY region

This works. But now the rule "canceled accounts don't count as active users" exists only in this view. When an agent queries the raw users table, or when a different team builds a dashboard, they have to rediscover and re-implement the same logic.

What Actually Happens

Rule duplication: Same business logic gets rewritten in dbt models, Python scripts, BI tools, and agent queries. Each implementation drifts.

No single source of truth: "Active users" means different things depending on which query you run.

Invisible changes: Update the SQL view, but agents querying raw tables still use old logic. No error, just wrong results.

What's Needed

Business rules as separate, queryable metadata that SQL transformations reference rather than contain. The rule "canceled accounts don't count as active users" should be defined once and propagated across all systems that need it.