Minha opinião sobre regras de negócio no banco de dados

Summary of the video (technological concepts / product guidance)

Main stance

The speaker argues that business rules should generally not be centralized in the database. In most cases, this approach leads to systems that are harder to understand and maintain over time.

“It depends” exception (when DB rules can be justified)

DB business rules may make sense for 100% data-driven applications, especially in infrastructure/data transformation layers, where the goal is to transform and standardize incoming data.

Example scenario:

• Data arrives from Excel or other databases
• That data must be organized, transformed, and standardized for reuse

In these cases, the database can act as a data transformation tool, sometimes reducing or eliminating the need for a separate application layer.

Why the speaker is against most DB business rules

When you add many rules into the database, the logic becomes obscure and harder to reason about.

The speaker distinguishes between:

• Data rules: how data is handled to produce outputs via queries/operations
• Business rules: how reality works—e.g., complex domain calculations, constraints, tax/payroll logic, etc.

Because business rules reflect real-world complexity, they often lead to large and complex code paths that should be structured for maintainability, rather than embedded in DB artifacts like triggers or functions.

Maintainability and “single place of truth”

The speaker claims (based on experience) that centralizing business rules in application code is more sustainable.

Preferred separation:

• The DB should handle data storage/retrieval and queries
• The application should own the domain logic

In this approach, queries should focus on:

• optimized selects/inserts
• parameters
• computed data

…and not conditional business logic (e.g., branching rules about tax calculation).

Mapping domain behavior better in code than in SQL/triggers

The speaker argues that programming languages—especially object-oriented ones—represent behavior more naturally than just state.

They use an analogy (zoo/animals) to illustrate that real domain behavior maps well to:

• classes
• inheritance
• overriding
• composition

By contrast, in the database you’d rely on functions and triggers to express behavior, which they consider a weaker fit for complete domain modeling.

Database-first vs code-first clarification

The speaker notes that database-first doesn’t automatically mean “business rules in the DB.”

It can mean:

• model data structure first
• then build the application

…but business logic still belongs in the application.

They also reference DDD (Domain-Driven Design) / the Raven methodology (as mentioned) to argue that domain-first (business-guided) development is more appropriate than starting from persistence concerns.

Disclaimer: still learn SQL (performance and correctness matter)

Even if business rules live in the application, the speaker insists you must understand SQL to ensure correctness and performance, including:

• effective manual/performance-select
• indexes and their impact on execution
• how ORMs translate queries (e.g., Entity Framework generating SQL and execution behavior)
• ensuring generated SQL is efficient (via execution plans and translation quality)

---

Main speakers / sources (as identifiable from the subtitles)

• Primary speaker: An individual expressing personal engineering opinions (no specific name given in subtitles).
• Referenced concepts/tools: SQL, triggers, functions, object-oriented programming, DDD, Entity Framework, and Raven methodology (as mentioned), but no specific external author/source is cited.