When we wrote the Standards, we knew that VIEW updatign is an NP-Complete problem, so we went with the easiest definition for the Standards.

student_name like ‘%N%’

It requires an index scan for the entire leaf-level of the IDX_STUDENT_NAME_CITY index. It’s expensive either before the collapse of the union or after. This use of a leading % negates the use of an index “well” but can be done with an index scan rather than a table scan. For a 1GB Customer table and 100MB index – it’s better to scan the index, right? But still poor query processing as a CSR doing a query with %N% for name is a drag on the system if they do it because they are too lazy to type in a name. Also, some developers pre-load the leading % in some systems (I contract at one of these places). That is fine with today’s large caches and fast processors – but 10 years ago, this code wouldn’t have been allowed.

We do see the improper use of UNION at customer sites a lot when they use:

SELECT DISTINCT ….
UNION
SELECT DISTINCT ….
UNION
SELECT DISTINCT ….

I continuously have to tell developers not to use DISTINCT when paired with UNION since the UNION itself is a distinct-resulting operator.