В принципе разницы нет. Оптимизатор, обычно и сам все правильно сделает. Но пару недель назад был топик про идиотизм оптимизатора. Отлистните пару страниц, я, честно, не помню его названия..

Соглясен с Alexander_Chepack, но в вопросе не было упоминания об OUTER. По моему, при OUTER, быстрее будет при "большой" к "маленькой". Но OUTER, на то и OUTER, что бы решать специфические задачи и результат "Большой" к "Маленькой", не будет иметь смысла, если надо наоборот. И как себя поведет оптимизатор, можно выяснить только пробными запусками.

Тут с индесами надо крупулезно работать.

Re Alexander_Chepack
Я вообше с подозрение отношусь к VIEW и никогда его не использую. Всегда ведь существует другое решение, через "#temp".
Меня приводит в замешательство невозможность ORDER BY.
Один черт, по моему, реально все эти VIEW, через "#temp" и реализуются. Или я не прав?
Я не крупный знаток "ВНУТРЕННОСТЕЙ".
Дед Маздай - помоги.

Наука... Только эксперимент является критерием истины.

Функции точно не создаю. Я с большими сомнениями на семерку перешел. А 2000 у меня вообще большое сомнение вызывает. Не потому, что я его досконально протеститровал. Просто у продукции M$, чем выше версия, тем она удобнее и тем больше содержить дыр в безопасности и устойчивости. Мне до сих пор страшно, что я не могу использовать в стандартную систему безопасности, без INTEGRITY.
Сейчас я не исключаю варианта о переходе на продукцию о которой дядя Билл имеет смутное представление. Причем я нисколько не хаю 6.5. Примерно 45000 часов без проблем, по формуле 24х7 меня убеждают больше, чем любые тесты.
----------------
Все обработки данных я использую ТОЛЬКО через ХП.
---------------
Объектно-ориентированное программироване, тут вроде бы как не причем (7 - я про 2000 ничего не знаю!). Хотя вроде это тоже не объектно-ориентированная СУБД.(Не трогаю клиентов!)

А структурное... Неоднозначный это вариант. Оно для больших коллективов (из предложения выкинуто "и для ламеров"). Причем в этом утверждении я противоречу себе, отвечавшему на некоторые ответы.

Повторное использованеи кода? На уровне клиента - сколько угодно! А в базах... Вроде как бы до сих пор нет точной договоренности даже об именах системных таблиц.

Насколько я знаю, VIEW были придуманы для облегчения и ограничения
пользовательских запросов на выборку.

Я читал в какой-то книжке, что штатовских бухов обучали SQL в прямой работе с базой. (Если это вранье, то пусть заграничные участники меня поправят и ткнут носом). Но сейчас-то? У пользователя выбора нет, что мы ему сделали в клиенте, то он и получит.

Действительно, если пользователь работает непосредственно с SQL-запросами, то view хорошо помогает и упростить запрос и ограничит выборку.

Честное слово, никогда не слышал об корректном обновлении данных через VIEW. Вернее читал, что, разные клиенты это делают по разному. А зачем мне неоднозначность, которая может менятся от версии к версии? Да и не каждый VIEW позволяет делать обновление.

В общем, я остаюсь при своем мнении, что VIEW, это рудимент.

Ура! Топик нашелся. А то я хотел ответить, но не мог вспомнить куда.

Я вообще странная личность.
Не люблю VIEW, тригеры и ссылочную целостность.
Так же не люблю VBscript, SmallDatetime, float, мексиканские сериалы, щи (без разницы, из какой капусты) и теплое пиво.

Люблю -
begin transaction
...
commit transaction

Ну бжики такие у меня. Имею право.
(А я сошла с ума! Тра-ля-ля!)