Public-health clinic triage scripts need a reusable calculation that maps height and weight inputs to BMI bands. Which programmability object should they implement?
Select an answer to reveal the explanation.
Short Explanation
You can use a scalar user-defined function as one shared BMI calculator, so each triage script applies the same height-and-weight mapping. A stored poster image, graph vertices, and a columnstore index do not provide that reusable calculation.
Full Explanation
Clinic triage scripts need one shared calculation that maps height and weight inputs to BMI bands, ensuring every municipal application uses the same clinical banding rules. A scalar user-defined function encapsulates that deterministic mapping and returns a single band value to T-SQL callers, centralizing maintenance when thresholds change. An external table over a stored BMI poster image may expose the picture, but it does not calculate bands from given inputs. A graph node table that treats BMI bands as incident vertices misuses graph modeling for a numeric classification function. A columnstore index accelerates scans and compression; it does not evaluate BMI formulas during compression. Caveat: scalar UDFs can inhibit parallelism or add CPU overhead in set-based queries. Keep the function simple, consider inlining options available at your Azure SQL compatibility level, and avoid unnecessary per-row calls in huge analytical batches when a set-based expression would suffice. Practical check: invoke the function with known height-and-weight pairs that fall into different BMI bands and confirm the returned bands match the clinic’s published thresholds; then call it from a small triage SELECT to verify callers receive the scalar result.