Вообще-то, и партиционирование может быть в конкретном случае хорошим вариантом.
Партиционировать надо по такому критерию, который позволит в дальнейшем:
- работать с набором таблиц наиболее простым образом,
- поможет оптимизации выполнения запросов на выборку данных в большинстве случаев.

Пример реализации А.
В многочисленных случаях в качестве критерия партиционирования подходит дата создания записи. В этом случае:
1. Запись всегда осуществляется в таблицу, соответствующую текущему периоду - что хорошо, потому что код заполнения таблицы получается ничуть не сложнее, чем в случае с одной таблицей.
2. Предусматривается процедура "закрытие старого / открытие нового периода", которая создает таблицу-часть, соответствующая новому периоду и устанавливает на нее хранящийся где-то контекст работы с периодами. Предыдущая таблица-часть объявляется недоступной для дальнейшего редактирования (закрытой).
3. Для выборок можно:
- либо сделать допущение: выбираем только из одного периода за раз (тогда тот же select, который мы бы написали для единой таблицы, полностью подойдет, только придется как-то фразу "from" определять до выполнения этого запроса),
- либо немного усложнить код, например, формировать составной select union select динамически (но период, интересующий пользователя, все равно надо запросить до того), или уже иметь параметризованный local view, в котором все объединения уже сделаны и осталось только подставить параметры, или обойтись без sql-операторов, обойдясь только командами xBase (или используя их комбинацию: несколько select-ов каждый раз из одной партиции в цикле с append-ами в общую выборку).

Пример реализации Б.
То же, что и A, но изначально мы пишем в "оперативную" часть таблицы, откуда потом (уже после того, как запись получит атрибут "закрыта окончательно" - т.е. дальнейшего редактирования записи уже не будет) разносим в части-партиции для архивного хранения. Соответственно, в запросах объединяем (по обстоятельствам) не только к части-партиции, но и оперативную часть.

Лично мне милее вариант Б.

Но вариант А лучше оптимизируется.