Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Danchik, Вы писали:

D>>Как автор даной оптимизации, скажу что здесь непорядок. Сабселект тоже надо убрать. Займусь на досуге.
D>>Ну и хотелось бы чтобы пользовались новыми, легко читаемыми, расширениями для джоинов LeftJoin
S>Ещё я тут не разобрался, как объяснить движку, что OrderID — это ForeignKey. Тогда устраняться должен и inner join, как не влияющий на rowset.

Ход ваших мыслей понял, вот не додумался до этого или забыл . Пока никак, движок пока работает только по primary key, и тут тоже уникальные индексы бы помогли, которые мы никак не учитываем. Гляну что можно сделать с foreign key, тоесть сделаю если вся необходимая информация есть в метаданных. Надеюсь никто матерится не будет если мы также пропроцесим foreign key созданный с хинтом with nocheck?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Danchik, Вы писали:

D>>Как автор даной оптимизации, скажу что здесь непорядок. Сабселект тоже надо убрать. Займусь на досуге.
D>>Ну и хотелось бы чтобы пользовались новыми, легко читаемыми, расширениями для джоинов LeftJoin
S>Ещё я тут не разобрался, как объяснить движку, что OrderID — это ForeignKey. Тогда устраняться должен и inner join, как не влияющий на rowset.

Ход ваших мыслей понял, вот не додумался до этого или забыл . Пока никак, движок пока работает только по primary key, и тут тоже уникальные индексы бы помогли, которые мы никак не учитываем. Гляну что можно сделать с foreign key, тоесть сделаю если вся необходимая информация есть в метаданных. Надеюсь никто матерится не будет если мы также пропроцесим foreign key созданный с хинтом with nocheck?

Все таки SQL сервер такое оптимизирует, но да, для других молодых баз данных это было бы ускорением.
https://sqlperformance.com/2018/06/sql-performance/join-elimination-unnecessary-tables