If this helps, I created a method using ***single‑row views*** that simulate ***enum‑like*** behaviour in T-SQL, and you can use it like this:
``` SELECT o.* FROM dbo.Orders o -- "enum" views CROSS JOIN dbo.en_OrderStatus s CROSS JOIN dbo.en_DeliveryType t WHERE ( o.OrderStatusID IN (s.Pending, s.Processing) AND o.OrderStatusID NOT IN (s.Shipped, s.Delivered) ) OR o.DeliveryTypeID = t.Mail; ```
You can find more details in the article: <https://www.sqlservercentral.com/articles/sql-server-enum-implementation-a-single-row-view-strategy-for-avoiding-magic-values>
Because of view expansion and constant folding, the optimizer will always embed the constants directly into the execution tree and eliminate the CROSS JOIN. *At some point I will update the article with a more precise explanation, including the note that the best way to create these views is by using the SCHEMABINDING option, which is missing in the original article.* 🙂

If this helps, I created a method using ***single‑row views*** that simulate ***enum‑like*** behaviour in T-SQL, and you can use it like this:
``` SELECT o.* FROM dbo.Orders o -- "enum" views CROSS JOIN dbo.en_OrderStatus s CROSS JOIN dbo.en_DeliveryType t WHERE ( o.OrderStatusID IN (s.Pending, s.Processing) AND o.OrderStatusID NOT IN (s.Shipped, s.Delivered) ) OR o.DeliveryTypeID = t.Mail; ```
You can find more details in the article: <https://www.sqlservercentral.com/articles/sql-server-enum-implementation-a-single-row-view-strategy-for-avoiding-magic-values>
Because of view expansion and constant folding, the optimizer will always embed the constants directly into the execution tree and eliminate the CROSS JOIN. *At some point I will update the article with a more precise explanation, including the note that the best way to create these views is by using the SCHEMABINDING option, which is missing in the original article.* 🙂