объявляю себе пятницу

не проверяя, что в календаре

SELECT DISTINCT tblArtikul.Artikul
FROM tblArtikul RIGHT JOIN tblModelsInArtikul
ON (tblArtikul.ID_Artikul=tblModelsInArtikul.Id_Artikul
AND (tblModelsInArtikul.ModelInArt="N040" OR tblModelsInArtikul.ModelInArt="P001"))

лажанулся малость - действительно, сказано надо обе
ПАРДОНС

авторПро "exist" не скажу - с ходу не придумаю, а вот зачем нужны "in" и "not in"?
Кроме того как "для облегчения понимания текста запроса"?
Я не могу придумать запрос, в котором эти операторы нельзя было бы заменить на один из join ... where. И выполняться последние будут в худшем случае не медленнее
вот даже читать такое удивительно - Вы, батенька, так людей заиками переделаете ;)

exists (not exists), In (not in) - операторы работы с МНОЖЕСТВАМИ, которые могут быть двух типов: фиксированный набор значений (бессмысленно для exists) или множество, получаемое путем выборки. (см вариант от (c)VIG
авторselect a.Artikul
from tblModelsInArtikul t inner join tblArtikul a
on t.Id_Artikul =a.Id_Artikul
where t.ModelInArt='N040'
and exists
(select * from tblModelsInArtikul t2 where t2.Id_Artikul =t.Id_Artikul and t2.ModelInArt='P001')

который через In переписывается так (не единственным способом):

select a.Artikul
from tblModelsInArtikul t inner join tblArtikul a
on t.Id_Artikul =a.Id_Artikul
where t.ModelInArt='N040'
and t.Id_Artikul IN
(select t2.Id_Artikul from tblModelsInArtikul t2 where t2.ModelInArt='P001')

По факту исходый вариант будет работать быстрее, НЕ ТОЛЬКО потому, что налагает более жесткое условие на выбор из t2, но и потому, что проверка на СУЩЕСТВОВАНИЕ множества (достаточно убедиться, что записей >0) (почти) всегда быстрее проверки на попадание в множество (перебор значений). Когда разработчикам удается сделать IN по времени выполнения не хуже exists для каких-то конкретных ситуаций - они пишут об этом самыми крупными красными буквами на заглавных страницах своих сайтов.

по времени выполнения варианты от (c)VIG и GEO (кажется абсолютно) эквивалентны, при этом вариант GEO, может быть переписан совсем без where примерно так:
select a.*
from
(tblArtikul as a inner join tblModelsInArtikul as b on a.id_Artikul=b.id_Artikul AND b.ModelInArt="N040")
inner join tblModelsInArtikul as c on a.id_Artikul=c.id_Artikul and c.ModelInArt="P001"

вариант от Владимир Саныч выглядит как несколько отличающийся по плану исполнения, поскольку один поиск по индексу заменен на группировку с последующим отбором значений по счетчику. На небольших множествах поиска и сравнения, кажется он будет самым быстрым.


Это же ОПЕРАТОРЫ, и In и exists и = и AND ...
Ваше право их применять при формулировке условия отбора - внутри where
или как часть выражения Join ограничивается только умениями конкретного планировщика запросов, а не логикой языка.
Например, до версии 2000 Access как помнится, совсем не умел работать с выводимыми таблицами в выражении From, да и сейчас (2000-2002) его умения в это части сильно ограничены. В то же время он вполне прилично справляется с выражением Where.

а моя мысль после пардонса пошла совсем по ложному пути.
В этом прелесть того, что настоящим языком является - одно и то-же многими способами сказать возможно, и в каждом выражении - своя поэзия. Более того - слово структуру мысли задает - назвал яхту бедой - и не получил рабочего запроса.
-)
вот кажется суббота подобралась и холодильник опять пустой...

авторЕсли же в "in"/"not in" используется подзапрос , то тогда действительно использовать JOINы гораздо лучше ( с точки зрения производительности)
-)
а вот с этим я не согласен, не взирая на пустоту холодильника.
ладно, пошел затариваться - не знаю вернусь ли -)