Цитата:
пользуюсь 2000
проблем (ORvsIN) не наблюдал (речь разумеется о логически эквивалентных условиях)

Пожалуй, стоит написать небольшое пояснение.

Когда я только начал работать в RiK-центре, и познакомился с 1С++ и прямыми запросами, одним из первых моих заданий была доработка отчета.
Я дописал запрос - и отчет начал формироваться вместо пары секунд секунд 30..40.
Начали с Олегом (Садовниковым) курить план запроса - выявили сваливание в Table scan на условии вида OR.
По совету Олега заменил OR на абсолютно идентичный IN(значение, значение) - сразу Table Scan ушел в небытие, и запрос стал выполняться с прежней скоростью.

Не исключено, что там и без того было понаворочено условий, что появление OR просто сносило крышу планировщику запроса. Но факт остается фактом и на неокрепшие (в тот момент) мозги это оставило неизгладимое впечатление.
С тех пор у меня есть непререкаемое правило: там, где OR равнозначно заменяется на IN - использовать IN. К тому же - это куда более читаемо.

Так что, за свою категоричность приношу извинения, но все же мягко рекомендую использовать IN() вместо OR.

Z1 писал(а) 09. Февраля 2011 :: 06:32:

Я бы не был столь категоричен, ведь в условии OR в первой части могут использоваться одни поля, а во второй - другие. Из-за этого, в сложных запросах, планировщик мог "перестраховаться" и уйти в TableScan. Тогда как при использовании IN мы явно указываем, что работаем с одним и тем же полем, что, ИМХО, проще для анализатора запроса.

Я бы сначала выгрузил во временную таблицу контрагентов по условию:

($Контрагенты.Поставщик = 0)
		|   And (Not(Контрагенты.Descr Like 'яя%'))
		|   And ($ФизЛица.ЯвлМенеджер = 1) 

А потом получал остатки уже по фильтру из временной таблицы.