Цитата:
Сообщение от
SRF
Хоть и было, это давно, но все же спрошу, а действительно ли прирост был в 6 раз, ну или хотя бы в 2 или 3 раза ?
Действительно, подсчет строк не самый, наверное, лучший вариант для определения, есть ли записи в таблице или нет, но замечу, что во всех таблицах, на которых есть этот волшебный метод, присутствует индекс VoucherIdx, в состав, которого входят оба поля, так что подсчет количества строк должен быть сравним с поиском первой записи по времени, по крайней мере для повторных запросов.
Цитата:
Сообщение от
fed
Стоит помнить, что для складских журналов можно настроить режим, при котором один ваучер выделяется не на строку, а на все строки с одинаковой датой . Для этого случая - гипотеза о сопоставимости времени выполнения count() и загрузки одной строки не срабатывает...
Да и в режиме Номенклатура+дата, выделение нового ваучера происходит только если в очередной строке номенклатура отличается от номенклатуры в предыдущей строке. Если у тебя, скажем, списывается много одинаковой номенклатуры с разными серийными номерами - гипотеза тоже не срабатывает.
Да, когда выделяется один ваучер на весь журнал, то может быть сотня тысяч записей, все с одним и тем же значением полей в индексе.
И для выбора одной строки скорее всего будет использоваться кэш, поэтому сильно снижается время на выборку.
Только что знакомый мой попробовал симулировать данную ситуацию, создав табличку, соответствующий индекс, т.д. Кол-во записей - 100 тысяч.
Для выбора одной записи потребовалось:
CPU time: 0 ms, Elapsed time: 0 ms
Для выполнения подсчета записей потребовалось:
CPU time: 16 ms, Elapsed time: 100 ms
Результат, соответственно, таков, что время выбора одной записи лучше в 100 раз (на самом деле, в бесконечность, но кто считает
)
P.S. Расчет был с использованием индекса по integer полю. Для индекса по нескольким полям, тем более строковым, разница будет еще больше.