SQL Server: дизайн: встроенный оператор Select или INNER JOIN? - PullRequest
0 голосов
/ 18 ноября 2009

У меня следующая структура таблицы -

Сайт: Мастер-таблица для сайта

Орг: Главный стол для Орг

Пользователь: Основная таблица для пользователя (каждый пользователь связывается с уникальной организацией через User.OrgId)

OrgSite: Сохранение некоторых «специфичных для Org» деталей сайта (OrgId, SiteId, SiteName, SiteCode). Не ВСЕ сайты, а только те, которые доступны для Орг.

UserSite: Ссылка пользователя на его доступные сайты (UserId, SiteId). Как пользователь связан с Org UserSite будет подмножеством таблицы OrgSite.

ItemSite : Таблица, в которой хранятся некоторые данные об элементе и сайте (ItemID, SiteId, OrgId, ...)

Теперь мне нужно отфильтровать \ отобразить записи с «ItemSite», и в этом случае мне также нужно отобразить код сайта. Итак, я вижу следующие два варианта -

1. Создайте VIEW: vw_ItemSite_UserSite_OrgSite (INNER СОЕДИНИТЕ все таблицы на SiteId) - это даст мне доступ ко ВСЕМ деталям Org, доступным в таблице 'OrgSite' (т. Е. SiteCode и т. Д.)

Если вы можете заметить, я должен включить «OrgSite» в представлении только потому, что я хотите Org конкретный SiteCode & SiteName. Потому что пользовательский сайт уже фильтрация сайтов - так что я могу «исключить» таблицу OrgSite и устранить ненужное ВНУТРЕННЕЕ СОЕДИНЕНИЕ.

2. На основании вышеупомянутого примечания - второй вариант - создать VIEW: vw_ItemSite_UserSite и в операторе SELECT VIEW я могу встроить следующий SELECT, например -

CREATE VIEW vw_ItemSite_UserSite AS
SELECT ItemSite.SiteID,
(SELECT TOP 1 [SiteCode] FROM OrgSite WHERE OrgId = ItemSite.OrgId) AS SiteCode,
...
FROM ItemSite INNER JOIN UserSite ON ItemSite.SiteId = UserSite.SiteId

Мое единственное намерение состоит в том, чтобы - я верю, что INNER JOIN и WHERE будут оцениваться до оценки встроенного оператора select. Итак, это спасет меня от производительности? Или лучше использовать vw_ItemSite_UserSite_OrgSite.

Вариант № 1 или №2?

Спасибо.

Ответы [ 3 ]

2 голосов
/ 18 ноября 2009

Остерегайтесь Преждевременная оптимизация . Если оба запроса возвращают один и тот же результат, используйте тот, который легче понять и поддерживать. Задача SQL Server - убедиться, что операции запроса (join, select, ...) выполняются в порядке, оптимизирующем производительность. И, как правило, SQL Server неплохо справляется с этим.

Тем не менее, - это некоторые случаи, когда анализатор запросов SQL Server не находит оптимальный план запроса, и вам необходимо настроить себя. Однако это редкие случаи. Если у вас уже нет проблем с производительностью в вашем запросе (и они не могут быть исправлены путем введения отсутствующих индексов), это то, о чем вам не следует беспокоиться прямо сейчас.

1 голос
/ 18 ноября 2009

Я воспользуюсь подходом с простым ответом. Создайте несколько тестов, проверьте их на производительность и посмотрите, какой из них действительно эффективнее для вашей конкретной среды.

0 голосов
/ 18 ноября 2009

Вариант 1 почти наверняка будет быстрее, встроенный SELECT, как правило, плохая идея для производительности.

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

...