Which of the following is NOT one of the common categories for SQL CHECK constraints used to limit acceptable values?
-
ASystem date (e.g., tying acceptance to the server's current date in general)
-
BRange checks (e.g., quantity between 1 and 100)
-
CLists of values (e.g., status in ('N','A','H'))
-
DComparing one column value to another within the same table
-
EPattern checks (e.g., simple LIKE rules on codes)
Answer
Correct Answer: System date (e.g., tying acceptance to the server's current date in general)
Explanation
Introduction / Context:CHECK constraints are declarative rules attached to a table that validate each row against logical conditions. Understanding common patterns helps design robust, self-enforcing schemas.
Given Data / Assumptions:
- We compare typical categories of CHECK logic.
- We look for the option that does not describe a common category.
- CHECK operates per-row and is evaluated at INSERT/UPDATE.
Concept / Approach:Common CHECK uses include range checks, membership in a set, column-to-column comparisons within the same row, and simple pattern checks. While one can reference deterministic functions, loosely referring to “system date” as a general category is not standard; moreover, some systems restrict nondeterministic references in CHECK constraints to maintain consistency across statements.
Step-by-Step Solution:
Identify typical categories: range, set membership, inter-column comparisons, simple patterns.Note that “system date” is not a canonical category and can be problematic or disallowed depending on vendor settings.Therefore select ”System date” as the item that is not a common category.Verification / Alternative check:Vendor docs illustrate CHECK with expressions like col BETWEEN low AND high, col IN (...), col1 < col2, or col LIKE 'A%'; “system date” is a special-case function usage, not a category.
Why Other Options Are Wrong:Range checks / lists / column comparisons / pattern checks: All are standard and portable uses of CHECK constraints.
Common Pitfalls:Depending on nondeterministic functions (like current timestamp) in constraints can lead to nonportable behavior and unexpected validation results.
Final Answer:System date (e.g., tying acceptance to the server's current date in general)