Как определить число записей в DataSet без FetchAll?

← →
Карелин Артем (2002-11-28 11:53) [0]

Есть хранимая процедура для выбора данных из нормализованной таблицы и кучи справочников. Есть кверь, который выбирает нужные данные из ХП. Как быстрее определить сабж??
Я правильно понимаю, что на отдельный запрос типа select count будет требоваться столько же времени, как и на FetchAll??

← →
Alexandr (2002-11-28 11:55) [1]

нет меньше
по сетке данные не надо передавать как минимум
Но одинакого в любом случае не будет.

← →
exit (2002-11-28 11:56) [2]

Число записей в DataSet - DataSet.RecordCount;
Число записей в таблице SELECT COUNT(*) FROM TABLE

← →
Prooksius (2002-11-28 12:03) [3]

В FIBPlus есть такая штука, определять число записей при планировании. Попробуй, может с ХП будет работать.
Я там наткнулся на такую бяку, что при явном указании плана запроса эта функция не корректно работает - пишет ошибку, мол, такой план запроса использовать нельзя. Если ее отключить, то план вдруг резко становится нормальным. Я не разбирался, в чем проблема, т.к. м.б. ее уже пофиксили (я пользуюсь бесплатными комп., но старыми)
Вопрос 2: нет. На фетчинг надо тоже попределенное времмя. Если На Prepare тратится время гораздо больше, чем на фетчинг (сложная ХП или запрос), то ты практически прав, в противном случае - нет.

← →
Карелин Артем (2002-11-28 12:05) [4]

>>Число записей в DataSet - DataSet.RecordCount;
Это работает правильно после вызова FetchAll

← →
exit (2002-11-28 12:07) [5]

2Prooksius © >
> Вопрос 2: нет. На фетчинг надо тоже попределенное времмя.
> Если На Prepare тратится время гораздо больше, чем на фетчинг
> (сложная ХП или запрос), то ты практически прав, в противном
> случае - нет.
В чем же это он прав? В том, что получить все записи и получить одну запись (count) - одно и то же?

← →
exit (2002-11-28 12:11) [6]

2Карелин Артем © >
> >>Число записей в DataSet - DataSet.RecordCount;
> Это работает правильно после вызова FetchAll
Спасибо, что подсказал. Я для того и разделил эти два понятия, чтобы подчеркнуть: Число записей DataSet - не есть число записей в таблице.

← →
Карелин Артем (2002-11-28 12:17) [7]

Масштаб такой: база на 1-20 мулей записей. ХП возвратит от 1 муля(редко будет) до порядка 20 000 записей. Кверь возвратит от одной записи до нескольких тысяч. Такое не делал, вот и спрашиваю.
P.S. Ведь хочется быстро. Ну а про индексы я не забываю.

← →
Prooksius (2002-11-28 12:17) [8]

2 exit (28.11.02 12:07)
А в том прав, что если время планирования запроса гораздо больше времени фетчинга всех записей запроса с сервера, то временем фетчинга можно пренебречь. И в том и в другом случае остается только планирование - одно и то же.
Или я не прав?

← →
Alexandr (2002-11-28 12:25) [9]

2Карелин Артем ©
ты испытывал быстродействие своей программы на 20млн записей в таблице.
Тебя может ожитать большой сюрприз ;)
Если что - тоже в мыло.

← →
Карелин Артем (2002-11-28 12:27) [10]

Время планирования пока больше фетчинга. Но это на около 1000 записей в главной таблице и по 200-300 в справочниках.
Если время планирования не растет с числом записей, то фетчинг будет идти заметно дольше.
Растет ли время подготовки при увеличении масштаба? Я думаю нет, но полной уверенности нет.

← →
Карелин Артем (2002-11-28 12:29) [11]

>>ты испытывал быстродействие своей программы на 20млн записей в таблице.
Индексы нам помогут. Я верю в них.

← →
exit (2002-11-28 12:34) [12]

2Prooksius © >

> А в том прав, что если время планирования запроса гораздо
> больше времени фетчинга всех записей запроса с сервера,
> то временем фетчинга можно пренебречь. И в том и в другом
> случае остается только планирование - одно и то же.
> Или я не прав?

Что-то я ничего не видел в вопросе про планирование...

> Я правильно понимаю, что на отдельный запрос типа select
> count будет требоваться столько же времени, как и на FetchAll??

Отвечаю: нет, нет и НЕТ. Потому как кроме "планирования" потребуется еще и время на доставку всех этих записей, о чем нам уже говорил Alexandr ©.

← →
Alexandr (2002-11-28 12:35) [13]

1) при увеличении количества записей время препаре не изменится.
2) Попробуй. Где-то с миллиона пойдет нелинейное уменьшение скорости, плавно переходящее в вечный тормоз.
3) Хреново ты , видать испытывал Firebird прежде чем применить его в таком супер глобальном проекте.
Вообщем, видит бог не я первый про мыло начал. Так что, в мыло.

← →
Prooksius (2002-11-28 13:12) [14]

2 exit (28.11.02 12:34)
Блин! Объясняю еще раз.
При отправке запроса на SQL сервер этот запрос сначала планируется (компилится сервером)/(делается его Prepare)
Уже потом фетчатся записи по запросу от клиента.
Если время планирования больше в сравнении с временем фетчинга записей, то что FetchAll, что select count - одна малина, время практически одинаковое.

> Что-то я ничего не видел в вопросе про планирование...

Теперь видишь? Планирование (prepare, компилирование) запроса - неотъемлимая часть отработки поданного серверу запроса.

← →
Карелин Артем (2002-11-28 13:16) [15]

>>Если время планирования больше в сравнении с временем фетчинга записей, то что FetchAll, что select count - одна малина, время практически одинаковое.

В том и дело, что фетчинг долго может идти иногда.

← →
Prooksius (2002-11-28 13:32) [16]

2 Карелин Артем © (28.11.02 13:16)
Если ты работаешь не через FIBPlus, для интереса кинь на форму pFIBDatabase, pFIBTransaction, pFIBDataSet и попробуй в опциях установить определять кол-во записей при Prepare. Может, это будет быстрее, чем все остальное. Я не пробовал с ХП...

← →
Карелин Артем (2002-11-28 13:38) [17]

Материалы не совсем в тему, но близко:
http://www.ibase.ru/devinfo/delmany.htm
http://www.ibase.ru/devinfo/calcindex.htm
http://www.ibase.ru/devinfo/instest.htm
http://www.ibase.ru/devinfo/idx_cost.htm
http://www.ibase.ru/devinfo/hddspeed.htm
http://www.ibase.ru/mail.htm

← →
exit (2002-11-28 13:44) [18]

2Prooksius ©>

> Блин! Объясняю еще раз.
> При отправке запроса на SQL сервер этот запрос сначала планируется
> (компилится сервером)/(делается его Prepare)
> Уже потом фетчатся записи по запросу от клиента.
> Если время планирования больше в сравнении с временем фетчинга
> записей, то что FetchAll, что select count - одна малина,
> время практически одинаковое.

Не надо нервничать. Я просто никак в толк не возьму: зачем рассказывать прописные истины своими словами? Об этом умные люди книги написали. Надо полагать, товарищ Prooksius © прежде чем послать запрос, осведомляется у "SQL сервер": "А как у нас там с "временем планирования", можно ли сделать FetchAll? Мне бы таким образом количество записей в DataSet хотелось бы узнать. Или все же придется отдельным запросом SELECT count(*).". А можно узнать сколько он такую пургу будет планировать?

← →
Prooksius (2002-11-28 13:56) [19]

2 Карелин Артем © (28.11.02 13:16)
Не, я не прав. Вот сейчас проверил. Эта опция (psAskRecordCount) просто делает select count. Отпадает...

Как определить число записей в DataSet без FetchAll? Найти похожие ветки