логичнее не соединять, а использовать exists .
т.е. выборка from customer c

и не надо будет никакой distinct лепить

mrGuest2. "select *" - это Вас кто так научил писать? Бросьте немедленно.


ну уж точно не mrGuest учил :)
приведу цитату уважаемого мной автора по этому поводу
а соглашаться ли с Ициком Бен-Ганом или с mrGuest-ом -- личное дело каждого

Unlike most other cases, in this case it’s logically not a bad practice to use an asterisk (*) in the SELECT
list of the subquery in the context of the EXISTS predicate . The EXISTS predicate only cares
about the existence of matching rows regardless of the attributes specified in the SELECT list, as if the
whole SELECT clause were superfluous. The SQL Server database engine knows this, and in terms of
optimization, ignores the subquery’s SELECT list. So in terms of optimization, specifying the column
wildcard * in this case has no negative impact when compared to alternatives such as specifying a constant.
However, some minor extra cost might be involved in the resolution process of expanding the
wildcard against metadata info. But this extra resolution cost is so minor that you will probably barely
notice it. My opinion on this matter is that queries should be natural and intuitive, unless there’s a very
compelling reason to sacrifice this aspect of the code. I find the form EXISTS(SELECT * FROM . . .) much
more intuitive than EXISTS(SELECT 1 FROM . . .). Saving the minor extra cost associated with the resolution
of * is something that is not worth the cost of sacrificing the readability of the code .

по поводу всевозможных домыслов есть отличная сказочка
вроде дело было куда проще, чем create view with schemabinding

да, я тоже думаю, лень им было выцеплять основной селект,
поэтому и подзапрос тоже на предмет звезды шерстит.
но прикольно: если в основной селект зафигасить '*' (как строку, в кавычках, ну мало-ли, для красоты вывода),
то такую закавыченную звезду пропускает