Я только собираюсь переехать с BDE (Paradox) на FB. И вот решил поэкспериментировать ...

Сделал тестовую программу, которая делает вставку записей в таблицу. Записи вставляются группами, при этом засекается время на вставку группы записей. Перед вставкой группы запускается транзакция, а по завершении вставки группы транзакция подтверждается.
В качестве сервера использовал FB 1.5, программу писал на Delphi 5,
в тестах использовал компоненты IBX 5.04 и FibPlus 5.02.
Сервер и клиент рассполагались на одной машине. Коннект к БД был как к сетевой, т.е. 127.0.0.1:D:\test.fdb

Вставка делалась так 10 раз по 50 записей, 10 раз по 500 записей, 10 раз по 1000 записей, 10 раз по 5000, 10 раз по 10000 записей. Время для каждой из групп усреднялось, т.е. в результате получалось среднее время для вставки одной записи для группы из 50, 500, 1000, 5000, 10000 записей.

Так вот проявляется странная закономерность:
- если вставку записи в таблицу делать с помощью sql запроса находящегося в клиентском приложении, то запрос выполняется в 1,5-2 раза быстрее и проц нагружается на 30%-40% меньше, чем если тот же делать с помощью хранимой процедуры (а странно ведь говорят, что ХП хранятся на сервере и выполняются быстрее );
- чем больше записей в таблице, тем больше среднее время на вставку одной записи в группах с небольшим количеством записей 50, 500, 1000. т.е. получается, что в маленькие таблицы (около 10000 записей) выгодно вставлять записи группами по 500 записей, а в средние таблицы (около 1000000 записей) - группами по 5000 - 10000 записей.

Хотелось бы найти объяснения этим двум явлениям.

Так же как я понял, что не хорошо как раньше выдавать все записи на клиента по эго запросу, и что записи нужно выдавать как бы страницами
и для этого использовать конструкцию Select First x Skip y .... якобы она позволяет не нагружать сервер и сократить трафик ....
Но как она может сократить трафик и разгрузить сервер при ее текущей реализации, мне не ясно.
Допустим, клиент запросил Архив параметров за месяц с помощью запроса "select .... from ... where ..... order by ...." пусть кол-во записей удовлетворяющих этому запросу - 500000.
Чтобы не выдавать клиенту такого количества записей за один раз нужно добавить в запрос First x Skip y. Пусть записи будут выдаваться группами по 5000 записей, т.е. клиенту нужно будет вызвать запрос 100 раз.
при этом насколько я понимаю трафик ни сколько не сократится т.к. клиент, если не запарится жать на next, получит таки свои 500000 записей, а суммарная нагрузка на сервер возрастет. т.к.
для первого запроса x=5000, y=0, сервер выберет и отправит клиенту 5000 записей;
для второго запроса x=5000, y=5000, сервер выберет 10000 записей и отправит клиенту последние 5000 записей;
...
для 100 - го запроса x=5000, y=495000, сервер выберет 500000 записей и отправит клиенту последние 5000 записей.
т.е. начиная со второго запроса сервер будет вынужден выбирать лишние записи: для второго запроса 5000, для третьего 10000, ... для 100 - 495000.
Получается, нагрузка на сервер возрастет в арифметической прогрессии.
И помимо 500000 записей сервер еще выберет (5000+495000)*99/2 записей.
т.е. получается, что выдавать записи по страницам не выгодно.

Вот исходная таблица, в которую происходит вставка записей



Для вставки записей со стороны клиента я использовал следующий запрос (он был помещен в TpFibQuery и выполнялся с помощью метода ExecQuery, приблизительно такая же реализация этого запроса была и для IBX).



Скорость выполнения такого запроса при вставке записей группами по 50, 500, 1000, 5000 записей была в 1,5-2 раза быстрее, а загрузка процессора на 30%-40% меньше чем при выполнении любой из двух следующих XP, (они отличаются только способом заполнения поля DAT, в одном случае значение для поля DAT формируется у клиента, а в другом на - сервере):

// Первый вариант XP


// Второй вариант XP


Хранимые процедуры выполнялись как с помощью TpFibStoredProc из FibPlus так и с помощью TIBStoredProc из IBX. Для выполнения процедуры использовался метод ExecProc.

Хорошо с Select First X Skip Y все ясно: что такую фитчу лучше совсем не использовать.

Остается только один вопрос как заставить XP работать с такой же скорость к и у запроса на вставку со стороны клиента. Да пробовал удалить индексы, не помогло. Видимо дело в том
Andrey_ что FB при вызове процедуры проверяет валидность параметров, а потом при вставке опять проверяет валидность параметров (валидность в смысле соответствие типа данных, а не проверки по различным check-ам).