Используемые средства Delphi, FibPlus, FB 1.5

Есть база в ней несколько таблиц, в которых сохраняется состояние параметров объекта в определенные моменты времени. Ежедневно в такие таблицы добавляется порядка 28 000 – 30 000 записей в каждую, т.е. за месяц каждая таблица увеличится на 900 000 записей, а за год на 10 000 000 записей. Причем 10 000 000 записей в год как я чувствую это не предел, при худшем раскладе таблицы в год будут увеличиваться на 30 000 000, но не больше. Заказчик хочет чтобы данные в таблицах сохранялись как минимум за 1 год. По этим таблицам в программе нужно так же делать выборки (например выбрать значения группы параметров на определенный момент, или выбрать значения какого то параметра за определенный период для определения динамики изменения параметра за этот период и возможно для прогнозирования его будущих изменений, а так же другие запросы). Все эти запросы будут выполнятся довольно таки часто по этому хотелось бы чтобы выборка выполнялась не долго.
И вот возникла идея, а что если данные хранить не в одной большой таблице, а создавать отдельную таблицу для каждого месяца, т.е. тогда при запросе выбор будет происходить из одной сравнительно небольшой таблицы или из нескольких с объединением результатов с помощь Union. Потом так и удалять записи вроде проще т.е. по истечении какого-то периода будет просто удалятся таблица за целый месяц. Что плохо так это то, что запросы усложнятся в особенности с объединением результатов за несколько месяцев. А так же то, что необходимо проверять наличие таблиц за определенный месяц.
Хотелось бы услышать мнения по поводу такого подхода, т.к. как я на FB только переезжаю, а до этого использовал BDE + Paradox, на котором такой подход реализовывал.

Так же не ясно нужно ли после создания таблицы переподключаться к серверу, и как получить список созданных таблиц, а также относится ли создание и удаление таблицы к модификациям, число которых ограничивается 255. А также не ясно почему практически при любом действии (будь то вставка 1 записи, или выборка данных) сервер FB загружает процессор на 100%.

Так же не ясно как в с помощью FibPlus выбирать много записей >200000 он ведь при этом их помещает в память и когда она заканчивается начинаются жуткие тормоза (логично было бы как- то этим процессом управлять т.е. при больших выборках данные складывать в файл на диске, а при маленьких помещать выбираемые данные в память). Сейчас чую народ скажет, что возвращать такие наборы данных это не правильно, значит база организованна не верно и руки кривые типа только с BDE переехал. Но вот есть архив значений параметров его ужать или усреднить нельзя (ну или по крайне мере я не знаю как) и заказчик захотел отчет за месяц распечатать, то тогда придется делать такую большую выборку. Ну а как в данном случае поступить ? Хотелось бы узнать типовые подходы для решения таких задач.

To Demosphen спасибо вроде получилось.

В общем то хотелось бы услышать мнения по поводу храненеия данных
не в одной большой таблице, а в таблицах создаваемых ежемесячно. Не будет ли каких граблей и даст ли это какой нибудь ощутимый прирост скорости выборок, или такой подход создаст лишь лишние проблемы. На Paradox такой подход был не плох, а вот как он будет на FB ?

To alex_k
Железо скорей всего будет не лучше чем Celeron 1200, 128 ОЗУ, HDD 40 ГБ
да еще эта машина будет загружена другими задачами, кроме сервера FB. Лучшего ожидать не приходится. Для одного проекта, который делался и тестировался под Win2000 на нормальной машине, заказчик подсунул 486SX с 8 МБ ОЗУ; HDD 200 МБ; видеокартой, которая не держала 800x600 и 256 цветов; и с win95 (благо при создании проекта я учитывал, что его могут запустить под 98, по этому проект заработал даже в таких условиях, правда градиентные заливки выглядели плохо). Так что ожидать хорошего железа не приходится.

To Andrey_
Честно говоря, для меня это пока не очевидно ведь с математической точки зрения <10 и <=9 это одно и тоже.
На счет удаления, думаю, его уместно будет делать раз в месяц, а после него делать b/r. Хотя в случае с месячными таблицами выполнялось бы просто удаление таблицы за месяц, и никакой бы сборки мусора бы не было.

автор
Хм... Ну тогда следовало бы оценить насколько часто будут встречатся запросы к нескольким периодам. Если достаточно редко, то можно и разбить на таблици... Но я так ниразу не делал и хлопот не имел :)


В принципе для анализа динамики изменения параметров зачастую достаточно выбрать данные за последние 3-15 дней, т.е. в начале месяца выборка будет происходить по двум таблицам в средине и в конце по одной таблице. А потом, честно говоря, если пользователь захочет вдруг выбрать все данные за несколько >3 месяцев, то не ясно как быть в этом случае т.к. объем выбираемых данных будет очень большой. А если использовать FibPlus или IBX то они всю выборку помещают в память, что не есть гуд при таких выборках. Возможно, имеет смысл, вообще ввести ограничение, что выборку нельзя делать за период большей чем месяц, т.е. захотел посмотреть данные за два месяца, то сначала смотришь данные за один месяц, а потом за второй.
А кстати, а как обстоят дела с компонентами IBO, может они позволяют как - то задавать (или сами решают) где размещать выбираемые данные в памяти или в файле на диске.

температура это аналоговое значение, полученное с АЦП а практически у все АЦП есть такая фитча к плаванье последнего 1 - 2х разрядов, т.е. даже если температура в точке измерения будет постоянной, то измеренные значения будут колебаться (например 20 ; 20.1; 20.2; 19.8 и т.д.)