This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi I have a design question. I am about to write a program that collects information from an end user and then store this information somewhere. The most effective, and commonly used solution to this would be to store the gathered information in a database. But how should I do this in a platform independent way and so the solution is transparent to the end-user? Is it a good solution to ship the application with a small footprint database written in Java, Is there any open source solution I could use? Maybe I don�t need a database at all, can I use XML or properties files instead? I would greatly appreciate some suggestions or thoughts on this subject Regards Martin
TThe first question that comes to mind is: What do you have to do with this information later? The answer to that will suggest which direction to go. For a small footprint all java, open source database I don't think you can go wrong with Hypersonic (hsql) see the Sourceforge page here. Bill
using properties files or XML might lead to potential privacy and security problems. With databases there's generally some security where only people and applications with the correct username and password can get at the data. With XML and properties files you have all your precious information for everyone to read who can get at the directory.
Let the requirements lead you ... do you need the features of a database like ad-hoc queries, referential integrity, ACID transactions, ability to use a 3rd party reporting tool, security, etc? Or would the ability to view or hand-edit flat files be of value? Would distributing, installing and managing a database be too complex? Since you're not sure and the answers may change over time as you think about it or get the first batch of users involved or start to get huge volumes, you might put some effort into isolating the decision from the rest of your application. Build your own API layer with get, put, delete operations and hide the decision inside the smallest number of classes you can manage. In other words, try to make it not matter. Zat help?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
If your business case suggests an embedded persistence mechanism is the way to go, and if youre comfortable with deep xml, maybe a native XML database might be a solution. Apache Xinidice for example. Challenges such as representing objects and their references as XML and vice versa will be inevitable. Domify anyone?