Routines vs. triggers: which statement correctly contrasts their execution behavior and usage in a relational database?

Introduction / Context:
Databases support stored code in two broad forms: routines (stored procedures and functions) and triggers. Although both encapsulate logic close to the data, their execution models differ substantially. Understanding this distinction helps you choose the right tool for automation vs. explicit business operations.

Given Data / Assumptions:

• Routines are invoked explicitly by applications, jobs, or other routines.
• Triggers fire automatically when data events occur (INSERT/UPDATE/DELETE, sometimes DDL or login events depending on DBMS).
• Both are stored in the database catalog and can include SQL and procedural logic.

Concept / Approach:
Triggers are event-driven: when an event occurs on a table or view, the DBMS automatically executes the associated trigger code. Routines are command-driven: they execute only when called directly (for example, CALL proc(), SELECT func(...)). This difference drives design decisions for auditing, validation, and encapsulation.

Step-by-Step Solution:

Verification / Alternative check:
Create a simple BEFORE UPDATE trigger to log changes; it runs without an explicit call. Contrast with a stored procedure that runs only when invoked by name.

Why Other Options Are Wrong:
Explicit invocation for both is false; triggers are automatic.
Cannot access NEW/OLD is false; row-level triggers commonly access these values.
Not stored / no SQL is false; both are stored in the catalog and contain SQL.

Common Pitfalls:
Overusing triggers for complex business logic (hard to debug) or misplacing validation that belongs in constraints or application code.

Final Answer:
Triggers execute automatically in response to table or view events, while routines (procedures/functions) run only when explicitly invoked.