Business Logic in SQL

Business logic embedded in SQL transformations creates maintenance debt and makes rules impossible to reuse across systems.

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.