A Shipments table has a virtual computed column, TotalWeight, that is calculated from three other columns on every read. Most queries filter on TotalWeight, and plans show full scans that evaluate the expression for every row. Where supported by the DBMS, which change best improves these queries?
Select an answer to reveal the explanation.
Short Explanation
If you have to do the same arithmetic on every row every time you search, you'll never get a fast lookup. Store the computed value and index it, and the engine can seek straight to the rows you want. Indexing the three source columns separately is the trap; the filter is on their combination, not on any one of them.
Full Explanation
A virtual computed column is evaluated when it is read, so a predicate on it forces the engine to calculate the expression for every candidate row, typically through a full scan. Declaring the column stored or persisted makes the engine compute the value when the row is written and keep it on disk, and an index on that stored value gives the optimizer an ordered structure it can seek or range-scan directly. Many engines can also index a deterministic computed or generated expression, which achieves the same result. Indexing the three source columns individually does not help because the filter is on the derived total; the optimizer cannot use an index on one input to satisfy a predicate on the combined expression. A view that recalculates the value is the same per-row computation with an extra layer, so it still scans. Pulling the calculation into the application moves all rows across the network and filters them client side, which is slower and wastes bandwidth. Exam caveat: storing the column adds write overhead and storage, and the expression must be deterministic to be persisted or indexed. Operational check: compare execution plans before and after to confirm a seek on the new index, and measure insert and update time for the added cost.