Public-health intake must validate that phone numbers in free-text clinic notes match an expected pattern. Which T-SQL predicate function should they use?
Select an answer to reveal the explanation.
Short Explanation
REGEXP_LIKE is the pattern gatekeeper—does this note blob look like a real phone number or not? Aggregating JSON or walking graph edges will not answer that format question.
Full Explanation
Public-health intake validating that phone numbers in free-text clinic notes match an expected pattern needs a Boolean regex predicate. REGEXP_LIKE (or the platform’s regex LIKE equivalent) tests whether the note text matches the phone-number pattern and can drive CHECK-like logic in a procedure, a filtered QA query, or a validation step before the note is accepted.
JSON_ARRAYAGG aggregates values into JSON arrays; aggregating digits does not validate phone patterns in prose. A columnstore index compresses data for analytics; compression does not implicitly verify phone formats. GRAPH MATCH traverses node/edge relationships; phone strings in notes are not graph relationships unless you explicitly model them that way—which still would not replace pattern validation.
Exam caveat: regex dialect and function names differ across engines; anchor patterns carefully to avoid over-matching extension numbers or dates. Operational check: run REGEXP_LIKE against notes with a well-formed phone, a malformed fragment, and an empty note, and confirm true/false results match the intake policy before enabling enforcement. Prefer validating phones in a dedicated structured field when intake can collect them; use regex on notes as a safety net for free-text capture, not as the only system of record. Log match failures for privacy review when notes may contain unexpected personal contact data outside the intended phone pattern.