Эффективность SQL-сервера при присоединении таблицы к самой себе, а не в качестве выбора в подзапросе

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

У меня есть запрос, который агрегирует значения в таблице как подзапрос по-разному для разных столбцов, например. за транзакцию в данный день, транзакции в предыдущем месяце, предыдущие 6 месяцев, до этого, после этого. Я назвал основную таблицу псевдонимом tx, затем псевдонимом подзапроса как tx1.

SELECT 
    tr.transaction_value
    ,ISNULL(
         (SELECT SUM(tr1.transaction_value) FROM [MyDB].[dbo].[Transactions] tr1
         WHERE tr1.Client_Ref = tr.Client_Ref),0) AND tr1.Transaction_Date > tr.Transaction_Date 
     ),0) as 'Future_Transactions'
    ,ISNULL(
         (SELECT SUM(tr1.transaction_value) FROM [MyDB].[dbo].[Transactions] tr1
         WHERE tr1.Client_Ref = tr.Client_Ref),0) AND tr1.Transaction_Date < tr.Transaction_Date 
     ),0) as 'Prior_Transactions'
FROM [MyDB].[dbo].[Transactions] tr

Я хочу знать, если у меня есть 7 таких столбцов с подзапросами, определяющими таблицу 7 раз в подзапросах, возможно ли и лучше (более эффективно, более читаемо) создать tx1 как ВНУТРЕННЕЕ СОЕДИНЕНИЕ в запросе основной таблицы, а не воссоздавать это в каждом подзапросе, и если да, то как мне кодировать предложения WHERE? Спасибо :о)


sql-server subquery coding-efficiency
person Johnny C    schedule 28.10.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это должно быть эквивалентно и лучше работать.

SELECT 
    tr.transaction_value
    ,SUM(tr1.transaction_value) as 'Future_Transactions'
    ,SUM(tr2.transaction_value) as 'Prior_Transactions'
FROM [MyDB].[dbo].[Transactions] tr
LEFT JOIN [MyDB].[dbo].[Transactions] tr1 ON tr1.Client_Ref = tr.Client_Ref AND tr1.Transaction_Date > tr.Transaction_Date 
LEFT JOIN [MyDB].[dbo].[Transactions] tr2 ON tr2.Client_Ref = tr.Client_Ref AND tr2.Transaction_Date < tr.Transaction_Date 
group by tr.transaction_value
person UnhandledExcepSean    schedule 28.10.2016