04.03.2005, 11:03 | #21 |
Участник
|
Попробовал...
На форму положил три кнопки, на триггер OnPush каждой кнопки считается количество записей в таблице с фильтром по одному и тому же вычисляемому полю. Первая кнопка - COUNT, вторая - COUNTAPPROX, третья - REPEAT..UNTIL. Дальше начинаем нажимать на кнопки в разном порядке и записывать результаты :-) Среднее время подсчёта снижается за счёт кэширования, но REPEAT..UNTIL всё равно работает немного быстрее. Да, забыл уточнить: используется Navision database server. |
|
04.03.2005, 13:38 | #22 |
Участник
|
Цитата:
Сообщение от tyrex
Можно вставить два слова?
В случае если таблица Table содержит flow fields типа Sum, а также имеет немаленький размер (допустим >10 000 записей), то количество элементов в этой таблице быстрее посчитать не через Table.COUNT или Table.COUNTAPPROX, а через перебор всех элементов с суммированием переменной-счетчика. Баг навиженовского движка. COUNT посылает на SQL сервер команду: SELECT SUM(rows), SUM(reserved) FROM "Database".[dbo].[sysindexes] WHERE id = OBJECT_ID(@P1) AND (indid < 2 OR indid = 255)', N'@P1 nvarchar(30)', N'"Company Name$Table Name"' Это конечно в общем случае... И будь в той таблице хоть все кроме первичного ключа поля flowfieldами никакой разницы в скорости выполнения данной команды не будет. Другое дело если у вас есть некий flowfield в справочнике - например Net Change в клиентах. И накладывается фильтр "Net Change">2000.... Но это уже совсем другая история... |
|
04.03.2005, 16:16 | #23 |
Участник
|
нда..
как показывает этот пример - не только нету бага, но и дополнительная оптимизация применена в случае отсутствия фильтров на таблице, по которой count снимается. Shoorik, проверил и Ваш метод, только собрал результаты 1000 циклов во временной таблице и построил диаграмму различий времени подсчета этими двумя методами. Стоит ли удивляться тому что получил банального Гаусса. Короче, нету там никакого бага. Работает Count отлично. В том числе с фильтрами по вычисляемым полям. |
|