Почему SQL-запросы с функцией VBA работают так медленно?

Question

Я унаследовал приложение, которое делает следующий вид запроса в большом количестве мест:

select foo.f1, foo.f2, foo.f3 
from foo 
where foo.f4 = getFooF4() 

getFooF4 выглядит следующим образом

Public Function getFooF4() 
Dim dbCurrent As Database 
Dim rstBar As Recordset 

    Set dbCurrent = CurrentDb 
    Set rstBar = dbCurrent.OpenRecordset("Bar", _ 
              dbOpenDynaset, _ 
              dbSeeChanges) 
    getFooF4 = rstBar![myF4] 
    ''yes this appears broken... Bar only contains one row :-/ 

    rstBar.close 
    Set rstBar = Nothing 
    dbCurrent.close 
    Set dbCurrent = Nothing  
End Function 
'' Note: in my experimentation getFooF4 only runs once during the 
''  execution of the query. 

Это заканчивается работает довольно медленно. Если удалить getFooF4() из запроса с константой:

select foo.f1, foo.f2, foo.f3 
from foo 
where foo.f4 = 123456 

или параметр:

select foo.f1, foo.f2, foo.f3 
from foo 
where foo.f4 = [myFooF4] 

или с объединением:

select foo.f1, foo.f2, foo.f3 
from foo 
INNER JOIN bar ON bar.myF4 = foo.f4 

Он работает гораздо быстрее.

Почему?

функции: App написана и работает в MS Access 2003, фоновым базы данных SQL Server 2008.

Answer 1

Две вещи, чтобы улучшить эффективность (хотя только один или другой будет когда-либо применить к конкретному случаю, как это):

1. определить тип возвращаемого значения для функции, то есть, Public Function getFooF4() должен Public Function getFooF4() As Long (или независимо от типа данных). Без явного типа данных он возвращает вариант. На самом деле никогда не существует функции VBA, которая никогда не будет иметь декларации типа возврата - если она возвращает вариант (который отлично разумно, особенно когда вам нужно вернуть Null в некоторых случаях), определите его с помощью As Variant. s некоторый другой тип данных, явным образом определяю его.

2. объявить параметр в вашем SQL, чтобы оптимизатор запросов мог использовать эту информацию при расчете плана запроса. Это не применяется, если ваш ИНЕКЕ использует функцию для обеспечения критерия, но если вы используете ссылку на поле в элементе управления, вы бы заменить это:

.

select foo.f1, foo.f2, foo.f3 
    from foo 
    where foo.f4 = Forms!MyForm!MyControl 

...с этим:

PARAMETERS [Forms]![MyForm]![MyControl] Long; 
    select foo.f1, foo.f2, foo.f3 
    from foo 
    where foo.f4 = Forms!MyForm!MyControl 

Теперь, в любом из этих случаев, так как функция/параметр в ИНЕКЕ, она должна быть решена только один раз, так что даже если функция является неэффективной (как в данном случае , при этом он инициализирует переменную базы данных и открывает набор записей), на самом деле это не имеет большого значения.

Еще одна вещь, которую стоит рассмотреть - это заменить функцию простым DLookup(), который предназначен именно для этой цели. С другой стороны, так как значение приходит из таблицы, вы должны быть в состоянии присоединиться к его к одной строке таблице:

select foo.f1, foo.f2, foo.f3 
    from foo INNER JOIN Bar ON foo.f4 = Bar.MyF4 

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

Answer 2

И как его можно сравнить с:

r = getFooF4() 

select foo.f1, foo.f2, foo.f3 
from foo 
where foo.f4 = r 

Если это так медленно, как оригинал , тогда ответ прост: функция getFooF4() - это медленная часть.

Answer 3

Ваш образец с GetFooF4 не может быть оптимизирован ни сервером Sql, ни через Access. И возобновление этого rs все время очень неэффективно. Как правило, избегайте использования специальных функций или кода Access в ваших запросах. Это предотвращает Acces от отправки запроса «как есть» на сервер Sql. Вместо этого он должен загружать всю совокупность данных и обрабатывать их локально, что означает увеличение трафика и меньшую скорость.
См http://msdn.microsoft.com/en-us/library/bb188204(v=sql.90).aspx#optaccsql_topic2