Порядок оценки для нескольких ограничений соединения - PullRequest
2 голосов
/ 13 сентября 2011

Если запрос содержит соединение с несколькими ограничениями соединения, оцениваются ли ограничения в порядке слева направо или SQL Server определяет оптимальный способ их оценки?

В надежде прояснить я попытаюсь объяснить, почему я спрашиваю. Допустим, у меня есть таблица с именем Alpha и в ней есть два столбца в дополнение к стандартному идентификатору. Первый столбец называется Generic1 и представляет собой varchar (20). Второй называется Тип и является smallint . Если Type = 1 , тогда значение Generic1 будет фактически ID записи в другой таблице (назовем это Bravo ) , Если Type = 2 , то значение Generic1 будет представлять собой текстовое значение.

Я хочу написать следующий запрос:

select * from Beta b
left outer join Alpha a on a.Type = 1 and a.Generic1 = b.ID

Если я могу с уверенностью предположить, что SQL Server будет только пытаться сравнить a.Generic1 = b.ID ПОСЛЕ того, как он сравнил a.Type = 1 , тогда я не буду надо беспокоиться об ошибках приведения / преобразования. Я бы хотел, чтобы в SQL не использовался синтаксис, допустимый только в SQL Server, если это возможно.

Я предполагаю, что SQL Server оценивает их так, как считает нужным, поэтому мне придется добавить CAST , чтобы быть в безопасности.

Ответы [ 2 ]

3 голосов
/ 13 сентября 2011

Почему у вас есть такой смешанный столбец? Похоже, что должно быть отношение FK к Bravo, которое в настоящий момент, по-видимому, у вас нет способа принуждения.

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

... ON a.Type = 1 AND CASE WHEN ISNUMERIC(a.Generic1) = 1 
                    THEN a.Generic1 END = b.ID 
        /* Result of "CASE" implicitly cast to int*/

(Хотя вы, возможно, захотите использовать метод специально для целых чисел вместо этого, хотя isnumeric не гарантирует, что значение будет успешно преобразовано в int)

2 голосов
/ 13 сентября 2011

1) Никогда не полагайтесь на план выполнения, чтобы гарантировать, что несовпадающие типы данных будут совпадать.

2) Да, SQL Server будет оценивать a.Type = 1 первым. Иногда. Нет никакой гарантии, но в целом, когда оба оператора оцениваются в числовое значение, ошибка не выдается.

3) Все еще не зависит от этого. Если вам абсолютно необходимо использовать пародию на модель данных, которая зависит от типа, чтобы определить, имеет ли другое поле определенный тип данных, включите оператор CAST.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...