индексированного View ищу нулевые ссылки без INNER объединения или подзапрос

Question

Так что я унаследованную база данных со структурой таблицы, как это (упрощенной)

Create Table Transaction 
{ 
    TransactionId INT NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    ReplacesTransactionId INT 
    .. 
    .. 
} 

Так что я хочу, чтобы создать индексированный вид таким образом, что следующий пример будет возвращать только вторая роль (так как он заменяет первый)

Insert Into Transaction (TransactionId, ReplacesTransactionId, ..) Values (1,0 ..) 
Insert Into Transaction (TransactionId, ReplacesTransactionId, ..) Values (2,1 ..) 

Есть несколько способов создания этого запроса, но я хотел бы создать индексированное представление, которое означает, что я не могу использовать подзапросы, левый соединяющий или Excepts. Пример запроса (с использованием LEFT JOIN) может быть.

SELECT trans1.* FROM Transaction trans1 
LEFT JOIN Transaction trans2 on trans1.TransactionId = trans2.ReplacesTransactionId 
Where trans2.TransacationId IS NULL 

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

Любые предложения?

Answer 1

Что вы имеете здесь, это по существу иерархический набор данных, в котором вы хотите предварительно пройти иерархию и сохранить результат в индексированном представлении, но индексированные представления AFAIK не поддерживают это.

С другой стороны, это не может быть единственным углом атаки для вашей более широкой цели повышения производительности. Во-первых, наиболее очевидный вопрос: можем ли мы предположить, что TransactionId сгруппирован и индексирован ReplacesTransactionId? Если нет, это будут мои первые два изменения. Если индексирование уже хорошо, то следующим шагом будет просмотр плана запроса вашего левого соединения и просмотр, если что-то выскочит.

В общих чертах (не имея плана запроса): одним из возможных подходов может быть попытка конвертировать инструкцию SELECT в «закрытый запрос» (см. https://www.simple-talk.com/sql/learn-sql-server/using-covering-indexes-to-improve-query-performance/). Это, скорее всего, повлечет за собой некоторую комбинацию:

• Сокращение числа столбцов в ЗЕЬЕСТ (замена SELECT *)
• Добавление нескольких «включены» столбцы индекса на ReplacesTransactionId (либо в SSMS или с помощью предложение INCLUDES CREATE INDEX).

Удачи вам!