Доброго всем времени суток!
Продолжаю бороться с АСЕ. Прошу помощи :)
Задача такая: есть таблица заказов (Card_Order), у каждого заказаесть идентификатор (ID)
Есть таблица статуса заказов (Card_StatusHistory), которая ссылается на таблицу заказов по полю Card_Order_ID, имеет идентификатор статуса заказа Status_ID и дату присвоения этого статуса (Doc_Date).
Т.е. в последнюю таблицу для каждого заказа заносится история изменения его статуса.

Стоит задача определить текущий статус каждого заказа. Для этого я написал такой запрос:

Select
count(*)
from Card_Order CO
join Card_StatusHistory CSH on CSH.Card_Order_ID = CO.ID_CRM
left join Card_StatusHistory CSHLater on (CSHLater.Card_Order_ID = CO.ID_CRM)
and (CSHLater.Doc_Date > CSH.Doc_Date)
where CSHLater.Card_Order_ID is null
plan "(use optgoal allrows_oltp)"

Индексы на всех нужных полях стоят.
План выполнения запроса:
|ROOT:EMIT Operator
|
| |SCALAR AGGREGATE Operator
| | Evaluate Ungrouped COUNT AGGREGATE.
| |
| | |NESTED LOOP JOIN Operator (Join Type: Left Outer Join)
| | |
| | | |NESTED LOOP JOIN Operator (Join Type: Inner Join)
| | | |
| | | | |SCAN Operator
| | | | | FROM TABLE
| | | | | Card_Order
| | | | | CO
| | | | | Index : CardOrder
| | | | | Forward Scan.
| | | | | Positioning at index start.
| | | | | Index contains all needed columns. Base table will not be read.
| | | | | Using I/O Size 2 Kbytes for index leaf pages.
| | | | | With LRU Buffer Replacement Strategy for index leaf pages.
| | | |
| | | | |SCAN Operator
| | | | | FROM TABLE
| | | | | Card_StatusHistory
| | | | | CSH
| | | | | Index : CSHDoc
| | | | | Forward Scan.
| | | | | Positioning by key.
| | | | | Index contains all needed columns. Base table will not be read.
| | | | | Keys are:
| | | | | Card_Order_ID ASC
| | | | | Using I/O Size 2 Kbytes for index leaf pages.
| | | | | With LRU Buffer Replacement Strategy for index leaf pages.
| | |
| | | |SCAN Operator
| | | | FROM TABLE
| | | | Card_StatusHistory
| | | | CSHLater
| | | | Index : CSHDoc
| | | | Forward Scan.
| | | | Positioning by key.
| | | | Index contains all needed columns. Base table will not be read.
| | | | Keys are:
| | | | Card_Order_ID ASC
| | | | Doc_Date DESC
| | | | Using I/O Size 2 Kbytes for index leaf pages.
| | | | With LRU Buffer Replacement Strategy for index leaf pages.



Вопрос к гуру Сайбеза - есть возможность какими-то доп. средствами оптимизировать данные запрос? (вариант с тригером на таблице истории и полем Текущий_Статус в основной таблице мое начальство рассматривать наотрез не хочет - пугает слово триггер)

Попутно вопрос - если не сложно ткните носом в ссылки об общих описаниях оптимизации запросов на сайбез + более/менее внятном описании планов запросов. то что идет в родной документации не очень подходит... Там без разъяснения что и сколько занимает, что приоритетней, что быстрее, чего надо избегать и т.д.

Заранее спасибо

MasterZiv не совсем понял... Как последний статус?
Как его определить для каждой карты?

cherrex_DenА что вы еще хотите оптимизировать? у вас везде читаются индексы и только индексы("Index contains all needed columns. Base table will not be read.")!
Что еще вы хотите оптимизировать?

Вот этого я и боялся :)
Т.е. получается, что для данного запроса это "потолок" по быстродействию...

MasterZiv
Этот запрос сам плохой. Надо вам последний статус - так так и напишите.
Выберите последний идентификатор статуса из истории статуса,
а потом статус с этим идентификатором.


Здесь в том то и проблема что нельзя на идентификатор ориентироваться - только по дате можно контролить.

Т.е. вполне вероятна ситуация, что сначала прийдет статус допустим "2" с датой "2008-01-01"
а потом статус "1" с датой "2007-01-01" при этом идентификатор у последнего будет больше чем у предпоследнего...

Так вот данные затекают...

antandКстати, писать в таблицу истории можно и не по триггеру(начальство успокоится).
Но поле текущий статус в основной конечно нужно.

Завтра буду убеждать - что триггер это не есть зло :)...
Без триггера - вижу вариант только один - ХП по изменению статуса... Но есть маленькая проблема - в базу "гадят" с многих сторон и не только мое приложение - заставить всех вносить статус через ХП - еще та проблема :)...
Хотя если отобрать права на инсерт в историю и выдать только на запуск ХП... Вообщем ушел думать...

Кстати, все-таки если у кого есть ссылки на доки по оптимизации запросов + на работу с планами запросов - киньте плиз...

ХП тоже не очень оптимальный вариант на мой взгляд...
Она отлично сработает при добавлении инфы по одной записи.

А если необходимо сразу записать статусы для 1000 заказов? Как работать? Я вижу два варианта:
1) Через временную таблицу
2) Гонять курсор и для каждой записи из датасета (ХП, насколько я знаю датасеты на вход принимать не умеет)

Ни тот ни другой вариант мне не нравятся - имхо п.2 долго работать будет, а п.1 - дополнительная брешь в обороне :)