Ежедневно по 30000 означает, что 30000/24/60 = 20 записей в минуту, или по одному каждые 3 секунды (если процесс 24-часовой). Спросите у заказчика, так уж ли необходимо помнить каждое значение. Может быть имеет смысл _до_ введения в БД, усреднять скажем каждые 5 значений, и вводить только среднее от этих пять. Врядли температура так быстро будет меняться в рамках 15-20 секунд, чтобы это было важно для дальнейших анализов. Точнее, если реальное изменение температуры меньше или сравнимо с погрешностью измерения, то очень даже имеет смысл делать предварительное усреднение

Дело в том, что в параметр не один их много (1250) пишу я их раз в час
1250*24=30000.

Изначально я считал, что параметры инерционные (да и эксперименты ставил) и собирался писать их минимум раз в 4 часа, а еще лучше раз в 6 часов. А также вычислять производные (скорость изменения параметров ) раз в сутки, исключая тем самым суточные колебания температуры и записывать их в другую таблицу. А измерения и проверку выхода за допустимые пределы выполнять непрерывно. Это было бы разумно. Если с параметром что-то не то, то сработает предупредительная сигнализация, а если совсем плохо то аварийная. Используя выборки предыдущих измеренных значений и производных можно было бы делать выводы о динамике изменения параметра. Этот анализ как я задумывал должен был бы производится для параметров, у которых значение параметра или скорости изменения превысили предупредительный порог. Это бы облегчило бы жизнь операторам. И свело бы объем базы и количество выборок к минимуму.
Но заказчик сказал, что хочет, чтобы все это делалось раз в час не больше.
И хочет, что бы производные считались так же каждый час и ему побарабану то, что на эти производные будут влиять суточные колебания температуры ...
Вот теперь и приходится думать про то что бы хранить данные не в одной таблице, а разбивать их по месяцам ... А так же думать как уменьшить объемы выборок ... Можно конечно сказать, что мол select first 100000 .... а остальные записи отбросить но это не есть гуд.

В общем наверное все же остановлюсь на создании месячных таблиц, запросы вроде не сложные, а если еще не использовать Union а сделать все с помощью XP, т.е. в XP передается дата и время начала и конца диапазона, а ХР эта дата в цикле преобразуется в и мя соответствующей таблицы, потом делается проверка существования таблицы с таким именем, если таблица существует то из нее выбираем данные если нет, то получаем имя следующей таблицы … и так до тех пор пока не дойдем до конца заданного периода.
Еще при таком подходе не будет проблем с сборкой мусора при удалении данных за месяц.

To Zmeishe про массивы я тоже думал, ведь они хранятся как Blob отдельно от таблицы, что позволит уменьшить размер таблицы и следовательно увеличить скорость манипуляций с ней. Тем более, что FibPlus поддерживает работу с массивами. Но все же при работе с ними есть ограничения, да и я ведь только с BDE переезжаю для меня и без массивов все это не просто.

Для работы с большими выборками специально для FibPlus нашел нормальную примочку, которая позволяет изменять место расположение выбираемых данных в памяти или на диске в RunTime. Вероятно буду ее использовать, но не в первой версии прогрммы. Правда автор пишет что делал ее для для Delphi 3,4 и Fib 4.X , но я пробовал она и на Delphi 5 c Fib с 5.x вроде работает (с небольшими косяками). Вообщем если ее немного подправить и выкинуть из нее лишнюю функциональность то для выборки больших объемов данных будет самое то. Вот ссылки может кому пригодится http://stikriz.narod.ru/art/dataset1.htm , http://stikriz.narod.ru/art/dataset2.htm.

В общем всем спасибо. На этом тему закрываем.