If your database interaction can be caught in a small catalog of basic statements, then don't go with this idea - use a database persistence framework. There are plenty of commercial and even some open source ones around.
For general background material, read
this white paper on database persistence frameworks,
Rational's take on the subject and
this Cocobase white paper.
Where your database interaction is complex, a framework may not work. Instead, consider reading your SQL statements from a database-dependent properties file. Use PreparedStatement throughout so that arguments can be represented by question marks. If you do this, there's a good chance you can port to a different database simply by reconfiguring. Consider using a Map to hold the statements so you can give them meaningful names.
You don't need to use a properties file of course. Use whatever form of configuration is most convenient. Some use Strings in a special class which contains all SQL statements (which I don't like personally). For EJBs, you may store them in the bean's JNDI environment. If your application already has a system configuration file, you may consider putting them there.
The above options are not mutually exclusive. It is fairly common
pattern to use a persistence framework for the routine stuff, supplemented by a number of SQL statements where the framework would be too inefficient.
- Peter
[This message has been edited by Peter den Haan (edited June 14, 2001).]