Выделенная динамическая строка имеет другое значение, когда на нее ссылаются в предложении Where

Question

Я динамически выбираю строку, построенную с использованием другой строки.Итак, если string1 = 'David Banner', тогда MyDynamicString должно быть 'DBanne'

Select 
...
, Left(
    left((select top 1 strval from dbo.SPLIT(string1,' ')) //first word
    ,1) //first character
    + (select top 1 strval from dbo.SPLIT(string1,' ') 
        //second word
        where strval not in (select top 1 strval from dbo.SPLIT(string1,' '))) 
,6) //1st character of 1st word, followed by up to 5 characters of second word
[MyDynamicString]
,...
From table1 Join table2 on table1pkey=table2fkey
Where MyDynamicString <> table2.someotherfield

Я знаю, что table2.someotherfield не равно динамической строке.Однако, когда я заменяю MyDynamicString в предложении Where на полностью левую (left (функция) и т. Д., Она работает как положено.

Могу ли я не ссылаться на эту строку позже в запросе? Нужно ли создаватьиспользуя функцию left (left (и т. д.) каждый раз в предложении where?

Answer 1

Если вы сделаете это так, как указано выше, тогда ответ будет положительным, вам придется заново создать его в предложении where.

В качестве альтернативы вы можете использовать встроенное представление:

    Select 
    ...
    , X.theString
    ,...
    From table1 Join table2 on table1pkey=table2fkey
       , (SELECT 
          string1
         ,Left(
            left((select top 1 strval from dbo.SPLIT(string1,' ')) //first word
                 ,1) //first character
            + (select top 1 strval from dbo.SPLIT(string1,' ') 
            //second word
            where strval not in (select top 1 strval from dbo.SPLIT(string1,' '))) 
           ,6) theString //1st character of 1st word, followed by up to 5 characters of second word
         FROM table1
       ) X
    Where X.theString <> table2.someotherfield
      AND X.string1 = <whatever you need to join it to>

Answer 2

В SQL 2008 вы можете использовать псевдоним в ORDER BY CLAUSE, но не в предложении where.

Почему бы не обернуть вычисление в пользовательскую функцию (UDF), чтобы избежать нарушения DRY, а также чтобы сделать запрос более читабельным?

Если это имеет значение, вот статья , которая объясняет, почему вы не можете использовать псевдоним столбца в HAVING, WHERE или GROUP BY.