Если хочешь динамический SQL, храни все используя класс preferences. Параметры нумеруй и храни там же с указанием типа и разбодяжкой потом в коде в зависимости от типа. Сам запрос храни в preferences тоже. Напиши проверяльщик запроса, который будет тебе выдавать правильное ли количество параметров ты указал для запроса. Лучше всего будет, если ты для такого дела сварганишь отдельный проектик, обладающий интерфейсом.
Но все это относится к достаточно большим проектам с часто меняющимися требованиями, т.к. трудозатраты окупаются обычно после 10-ти таблиц и ежемесячным, влияющим на твое приложение, изменением структуры хотя бы в одной из них.
Очень подходит такой подход к развивающимся корпоративным проектам. Но в конце концов устоявшийся проект с устоявшейся спецификацией надо будет переписать в статичной форме, хорошо спроектировав структуру данных. Это может явиться спецификацией к генератору схемы из динамичных preferences.
Вроде как есть тулзины, помогающие делать такие вещи, но применительно к Oracle, т.к. они реализуют независимость от изменения структуры данных с помощью хранимых процедур.
Для DBF можешь сам написать сначала интерфейс к данным, который и будешь безболезненно относительно остального приложения менять. А в приложении пользоваться только этим интерфейсом - читай про шаблон Facade.