Choosing data types for robust schemas When selecting a column's data type, which goals should a designer pursue?

Introduction / Context:
Poor data-type choices propagate pain: wasted space, slow scans, and integrity problems. Picking the right type is foundational for performance and correctness across OLTP and analytics systems. This item tests whether you know the balanced objectives in type selection.

Given Data / Assumptions:

• Columns will store values repeatedly at large scale.
• Storage, integrity, and representational coverage all matter.
• Constraints complement but do not replace good type choices.

Concept / Approach:

Good schema design aims to minimize storage (without losing fidelity), correctly represent the domain (e.g., DATE for dates, NUMERIC for money), and enforce integrity (NOT NULL, CHECK, ENUM/domain constraints). These goals are not mutually exclusive; they reinforce one another when the correct type is used with constraints.

Step-by-Step Solution:

Verification / Alternative check:

Vendor guides and normalization practice emphasize domain-correct types with constraints to improve query plans and reduce anomalies, while right-sizing preserves I/O and cache efficiency.

Why Other Options Are Wrong:

• Option E elevates readability above correctness; databases should enforce correctness first.

Common Pitfalls:

• Using overly wide VARCHAR for codes that fit in SMALLINT or fixed CHAR.
• Storing dates/times as strings, which harms validation and indexing.

Final Answer:

All of the above.