AND and OR: Parentheses Make Predicate Precedence Clear

AND and OR have different precedence, so parentheses can change which rows satisfy a combined predicate. I write the intended grouping explicitly. A readable business rule should survive the addition of another condition.

Enumerate every present flag combination

The sample rows cover all eight combinations of three binary flags. Each flag is an integer zero or one. Missing values are intentionally outside this first truth table.

DefaultRule uses FlagA equals one OR FlagB equals one AND FlagC equals one. The AND condition groups before OR. Its expected meaning is FlagA alone, or the combined FlagB-and-FlagC requirement.

ExplicitDefault adds parentheses around FlagB and FlagC. Its expected output matches DefaultRule at every row. Those parentheses document the grouping already provided by operator precedence.

I return the raw flags beside each rule result. That makes every expected decision independently reviewable. A single filtered list would hide which rejected combinations distinguish the rules.

WITH Inputs AS
(
    SELECT CaseId,FlagA,FlagB,FlagC FROM (VALUES
        (1,0,0,0),(2,0,0,1),(3,0,1,0),(4,0,1,1),
        (5,1,0,0),(6,1,0,1),(7,1,1,0),(8,1,1,1)
    ) AS v(CaseId,FlagA,FlagB,FlagC)
)
SELECT CaseId,FlagA,FlagB,FlagC,
    CASE WHEN FlagA=1 OR FlagB=1 AND FlagC=1 THEN 1 ELSE 0 END AS DefaultRule,
    CASE WHEN FlagA=1 OR (FlagB=1 AND FlagC=1) THEN 1 ELSE 0 END AS ExplicitDefault,
    CASE WHEN (FlagA=1 OR FlagB=1) AND FlagC=1 THEN 1 ELSE 0 END AS SharedRequirement
FROM Inputs ORDER BY CaseId;

A shared requirement needs a different grouping

SharedRequirement groups FlagA OR FlagB before applying FlagC. Its expected meaning requires FlagC for either route. That differs from allowing FlagA to satisfy the rule alone.

At case five, FlagA is one while both other flags are zero. DefaultRule and ExplicitDefault expect one. SharedRequirement expects zero because the common FlagC requirement is absent.

Case seven also has FlagA one and FlagC zero. It exposes the same disagreement even though FlagB is one. Keep that combination beside the case where FlagB is also zero.

At cases four, six and eight, the expected rules agree on inclusion. An example containing only those cases would conceal the grouping defect. Boundary combinations make the distinction visible.

Translate the sentence into a parenthesized predicate

A business sentence might allow route A, or route B when a prerequisite is satisfied. Another sentence might require that prerequisite for either route. Similar words can describe different logical structures.

I would identify the alternatives and shared requirements before typing the predicate. Then write parentheses around the intended groups. That makes the rule easier to review without memorizing the precedence table.

Adding a new common restriction to the end of an OR predicate deserves special care. It can attach only to one branch if the alternatives remain ungrouped. Review the complete expression rather than just the added text.

Parentheses are useful even when they preserve the existing grouping. They communicate intent to the next reader. They also make a later change easier to assess against the original requirement.

Logical grouping does not promise an evaluation order

The precedence rule determines the expression’s logical grouping. It does not guarantee a procedural short-circuit sequence for every SQL expression. Do not rely on predicate ordering to protect an unsafe conversion.

This example contains only safe integer comparisons. It does not use divisions, conversions or function calls that can fail. That keeps grouping separate from evaluation-safety questions.

NULL inputs would introduce Unknown as a third logical result. A real nullable flag contract must test those states too. This complete binary truth table intentionally teaches precedence with present flags first.

Compare the default grouping with the explicit shared requirement across every flag combination. Agreement on accepted rows alone can hide a misplaced restriction. The rejected boundary combinations expose where the grouping changes the decision.

When reviewing a filter, include combinations that satisfy an alternative while failing the common restriction. Those rows reveal whether the restriction belongs to one branch or every branch. Agreement on ordinary accepted rows is not enough.

Parentheses cost nothing and save the next reader a guess.

A common requirement is not shared automatically, it is a grouping you write on purpose.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.