Здравствуйте, форумчане!

Задача такова. Идет технологический процесс, часто меняются значения параметров. Все изменения необходимо архивировать. К примеру, 1500-2000 параметров за секунду. То есть надо добавить в таблицу локальной БД пару тысяч записей (причем, не за 1 секунду, а гораздо быстрее, так как есть еще приличная визуализация). 
Причем, мое мнение, не записывать их на диск по отдельности, а сразу пулом (к примеру, 32к записей). 

Что использовать для этого Table или Query?

В книге Архангельского написано: "..при работе с локальными базами данных эффективность Query заметно ниже эффективности Table. Замедление вычислений получается весьма ощутимым."

Да, и хотел бы получить дельные советы от Вас, форумчане, как мне принципиально построить этот процесс (технологию) архивирования данных? С помощью промежуточных (виртульных) таблиц, которые потом сливать в реальные?

П.С. Использую ЛБД Paradox7

Заранее благодарю

А что ты собираешься сохранять - дискреты?

И дискретные, и аналоговые.

если Яковлевич пишет что TTable для локальной БД кайфовей поверим ему на слово. 

Тебе же предлагаю дискреты упаковывать в слова стояния - так будет рациональней. Считай в одно поле ты запишешь 16 дискретов супротив одного.

Так и делаю.
 Меня интересует, не захлебнется ли машина на таком количестве записей?
Каждые новые сутки лучше новую БД создавать? А то много сильно записей будет

Конечно каждые сутки создавай новую таблицу. В этом плане конечно TQuery эротичней. И потом еще не плохо было бы определиться как долго ты ее будешь на харде. За месяц знаешь ли хард может и забиться под завязку. Ты данные сливаешь каким образом - через клиента или по како-му нибудь промышленному протоколу?

Углублюсь еще в проект. До этого я архивировал в файлы (1 файл - 1 сутки) информацию потоком байтов (очень быстро, но сердито в плане извлечения архивных данных). Но большое время извлечения архивных данных заставило меня пересматривать стратегию архивирования. Т.е. наличие индексов в БД, возможность вытянуть информацию по имени сигналов и по времени с помощью несложного запроса - все это натолкнуло меня на мысль поработать с БД.
Данные тяну своим верхним уровнем с OPC-клиента.

А теперь, почему решил обратиться к форумчанам:
1) боюсь машина захлебнется от записи данных в БД. Хотя надо пробовать и смотреть. Может, кто-то предложит, подскажет, чему уделить внимание? построению индексов, записи сразу в файл большого куска данных (так я делал с обыкновенным файлом)? Еще чему-нибудь?
2) нет опыта работы с БД Paradox7, с этой технологией BDE (с БД работал только с применением технологии ADO.NET). Ну а тут надо под Builder 6 и скорее всего, Paradox7 (т.к. ЛБД). Поэтому думаю, что кто-то подскажет типа, бери Table (Query), создавай еще временный Table... 

PS С файлами решал проблему заполнения харда след.образом, проверял место на диске, и если оставалось чуток, то удалял самый старый архив (все программно)

По поводу что машина захлебнется. Пиши значения по изменению. Для этого вводят степень чувствительности для аналогов и изменение по дискретам. Никто не валит такой объем данных как ты гришь 1500 - 2000 значений менее чем в секунду.

Все верно. В реальности до 40 изменений в секунду. Есть и апертура всех сигналов. Пишу естественно по изменению.
Но!!! У меня есть демо-режим, где можно экспериментировать без реальных тех.процессов. Аналоговые представлены синусоидой, естественно, постоянно меняются. Так вот в таком случае, доходит до 2000 сигналов в сек. Ну, а для меня, если в таких условиях система выдерживает (пока что так и есть), то все ГУД! Значит, выдержит и на реальных тех.процессах, пока оператор будет в сапера играть или порнушку посматривать...

mrbrooks, так что Table vs Query посоветуете. И возможно ли темпово создавать Table без привязки к реальной таблице, и из него заливать в табл. БД. Хотя наверно лучше устанавливать CashedUpdates в true и далее ApplyUpdates и CommitUpdates... Ну а если Table привязана к таблице событий, то к концу суток понадобится слишком много оперативки, чтоб удерживать Table в памяти, а мне это не надо. Короче, что надо сделать (накидать на форму), чтобы таблица событий не занимала оперативки, но иногда можно было дописывать в эту таблицу новые события. Может, временный Table (хранит "свежачок", пока Query не сгрузит в табл.) и с помощью Query  дописывать в таблицу "свежачок" из этой Table?
И возможно ли в StringGrid выгрузит данные архива? Т.е. определенные сигналы за опр. время (все задается оператором). И что для этого использовать Table vs Query? 

Я бы остановился на TQuery. На мой взгляд это оптимальней при работе с большим колличеством  данных. Главное имхо как ты понимаешь для записи в БД не должно быть ни какой визуализации. То есть что бы не было желание посмотреть через DBGrid как оно там добавляется в бд