Добрый день!
Используемые инструменты: MS SQL Server 2005 + MS Visual C++ 6.0

Предыстория вопроса:

есть два преставления:
###############################################################################################
1 — vw_FullDataInfo

SELECT T2.number AS cnum, T1.status AS cstatus, T1.adddate, T1.description AS cstatusdes
FROM tbl_Table1 AS T1 WITH (nolock)
INNER JOIN tbl_Table2 AS T2 WITH (nolock) ON T2.id = T1.cref
INNER JOIN tbl_Table3 AS T3 WITH (nolock) ON T3.id = T1.cstatusref
###############################################################################################
2 — vw_ActualDataInfo

SELECT cnum, cstatusdes, adddate, cstatus
FROM vw_FullDataInfo AS T1
WHERE (adddate =
(SELECT MAX(adddate) AS date
FROM vw_FullDataInfo
WHERE (T1.cnum = cnum)))
###############################################################################################
Первое выдает ВСЕ данные по объектам
Второе выдает только АКТУАЛЬНЫЕ (с максимальной датой)

Из программы делаем два запроса ( не один за другим , а либо 1-й либо 2-й) :
1 — "select * from vw_ActualDataInfo"
2 — "собственно код самого представления vw_ActualDataInfo" , то есть SELECT cnum, cstatusdes, adddate, cstatus и т.д.

Суть проблемы:
Если использовать запрос (1) , то он выполняется ~ 50 сек
Если использовать запрос (2) , то он выполняется ~ 0.5 сек

Вопросы: почему так? что исправить?

PS: не скажу что являюсь крупным специалистом по части разработки БД ,
но по полученным результатам был ПРОСТО В ШОКЕ

PSS: работа через ODBC

Заранее благодарю за помощь!

Здравствуйте, SSN75, Вы писали:
SSN>Вопросы: почему так?
выбираются разные планы запроса
SSN> что исправить?
Для начала посмотреть, какие планы выбираются для запросов (1) и (2). Понять, почему не выбирается оптимальный план для первого запроса.
Далее, понять, как правильно использовать ranking функции в MS SQL 2005 и переписать запрос в более пристойном виде:

with t1 as 
  SELECT cnum, cstatusdes, adddate, cstatus, ROW_NUMBER() OVER (order by adddate desc) as rn FROM vw_FullDataInfo
select * from t1 where rn=1

SSN>PS: не скажу что являюсь крупным специалистом по части разработки БД ,
SSN>но по полученным результатам был ПРОСТО В ШОКЕ
Это совершенно нормально. Процесс освоения РСУБД вызовет шок еще неоднократно.

Здравствуйте, Sinclair, Вы писали:
S>Для начала посмотреть, какие планы выбираются для запросов (1) и (2). Понять, почему не выбирается оптимальный план для первого запроса.
Если не секрет: как посмотреть ?
S>Далее, понять, как правильно использовать ranking функции в MS SQL 2005 и переписать запрос в более пристойном виде:
К сожелению в более пристойном виде работает в ~8 раз медленнее...

Вот еще что: производительность оценивается из программы...
Если выполнять запрос с Query Analyzer-а ( или как он там 2005 называется ) то время выполнения на глаз не отличается...

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

SSN>Здравствуйте, Sinclair, Вы писали:
S>>Для начала посмотреть, какие планы выбираются для запросов (1) и (2). Понять, почему не выбирается оптимальный план для первого запроса.
SSN>Если не секрет: как посмотреть ?
Включить в SQL Server Management Studio опцию Show Actual Execution Plan (есть такая кнопочка на тулбаре редактора query)
S>>Далее, понять, как правильно использовать ranking функции в MS SQL 2005 и переписать запрос в более пристойном виде:
SSN>К сожелению в более пристойном виде работает в ~8 раз медленнее...
Странно. Тоже — смотреть query plan.
SSN>Вот еще что: производительность оценивается из программы...
Тогда первым делом нужно прицепиться к серверу при помощи Sql Profiler и посмотреть, что на самом деле выполняет программа. Профайлер заодно покажет, сколько времени сервер проводит за выполнением, и сколько там выполняется дисковых операций. После этого уже можно пойти SQL Server Management Studio и погонять реальные запросы. Прямо вместе с параметрами, бла-бла-бла.
SSN>Если выполнять запрос с Query Analyzer-а ( или как он там 2005 называется ) то время выполнения на глаз не отличается...
На глаз — не надо. Можно просто написать подряд два запроса, включить показ планов и сравнивать их side-by-side.