Hi,
I don't have an answer to your question, but a procedural approach. My project now
supports two unique databases, though the way the schema definition works is the
same; so, for instance, the number of fields per record could differ, and meaning
of a database column could differ, and the number of bytes per field could differ.
To keep things simple, and so that my
JUnit tests continue to work correctly, my
"second" database type is very similar to the original type, except that the number
of system bytes is different, and the number of bytes per record is different.
My suggestion, then, is procedural: at some point, for me, I did this later on in my
project, I introduced the second database; you might do the same and see where
things lead. By the time you get everything working, you may decide, or perhaps not,
that it is simpler simply to hard code the business layer so that it knows, implicitly,
that column 7 has a certain meaning.
Since keeping the business layer 'blind" about the meaning of a column is a form
of indirection, I would see know hurry to implement it immediately, as indirection
can be added during refactoring at a later stage if it is deemed necessary.
Thanks,
Javini Javono