Цитата:
Сообщение от
smoyk
Разве не так?
Это верно только для нативной базы.
Для SQL это не верно.
MS SQL Server самостоятельно выбирает ключи поиска и план выполнения запроса. Независимо от переданного ему ключа через функцию SETCURRENTKEY
пример:
Код:
recCustLedgerEntry Record Cust. Ledger Entry
________________________________________
recCustLedgerEntry.RESET;
recCustLedgerEntry.SETCURRENTKEY("Customer No.","Posting Date","Currency Code");
recCustLedgerEntry.SETRANGE("Customer No.",'C3438');
recCustLedgerEntry.SETRANGE("Posting Date",231106D);
recCustLedgerEntry.SETRANGE("External Document No.",'03');
recCustLedgerEntry.FIND('-');
Этот код приведет к выполнению следующего SQL запроса:
Код:
SELECT * FROM "dbo"."КРОК$Cust__Ledger_Entry"
WHERE (("External_Document_No_"='03'))
AND (("Customer_No_"='C3438'))
AND (("Posting_Date"='2006-11-23'))
ORDER BY "Customer_No_","Posting_Date","Currency_Code","Entry_No_"
Данный запрос будет выполнен по следующей схеме:
Параметры, переданные через SETCURRENTKEY, трактуется исключительно как порядок сортировки полученного результата (поле ORDER BY) и никак не влияют на выбор ключей, используемых при поиске.
Изменим вышеприведенный код, убрав из него вызов SETCURRENTKEY:
Код:
recCustLedgerEntry Record Cust. Ledger Entry
________________________________________
recCustLedgerEntry.RESET;
recCustLedgerEntry.SETRANGE("External Document No.",'SCI_604983/SZ622586');
recCustLedgerEntry.SETRANGE("Posting Date",200906D);
recCustLedgerEntry.SETRANGE("Customer No.",'C3137');
recCustLedgerEntry.FIND('-');
Этот код приведет к выполнению SQL запроса:
Код:
SELECT * FROM "dbo"."КРОК$Cust__Ledger_Entry"
WHERE (("External_Document_No_"='03'))
AND (("Customer_No_"='C3438'))
AND (("Posting_Date"='2006-11-23'))
ORDER BY "Entry_No_"
Сортировка в данном случае будет произведена по умолчанию, то есть по первичному ключу «Entry No.».
План выполнения запроса выглядит следующим образом:
Данный план выполнения лучше предыдущего, поскольку в нем отсутствует трудоемкая задача – сортировка конечного результата (сортировка входит в этап join’а таблиц).
Последний запрос в среднем в 5-10 раз быстрее первого (зависит от размеров таблицы)