New App Data Storage

[pnelsonsr]

A group has been using a VB app for a while and it uses an access db as its data storage. I've been tasked with completely redoing this in java. The application will be self-contained with the data local (with internet updates), but not a central connection to a db. So installation and local setup is a consideration. The access db is not huge (100MB-300MB) and is somewhat complex, but not overly.

I've always had to work around a set data environment and now find myself able to dictate it. So my question comes to "what should I do"/"what would you do"? Keep the ms access db. Go with another db. Use a java data storage environment.

I'd love to get some input on what would be the best ideas and direction to take while I can dictate it. What's worked what hasn't.

[~s.o.s~]

First advice; avoid the "big re-write". The worst thing you could possibly do would be try to phase out everything and struggle when something stops working. No matter what datastore you are accessing, using the DAO pattern should help you isolate the database/datastore specific logic to a fixed set of classes. Just ensure that you program to interfaces when accessing data and migrating to something different shouldn't be very difficult.

A few other points to help you get started:

• Start by analyzing the application and find out whether it uses any platform (Windows) specific stuff
• At least have a basic design of your application chalked out. A really bad thing to do would be to dive head first into implementation without having at least a rough idea of how the application might be structured when migrated to Java
• Have several small milestones which are followed by rigorous testing. Getting the users of the application to test your milestones would be a good idea
• Make database migration your priority only if you application has to be deployed on both Linux and Windows box

[pnelsonsr]

The redo is needed because they decided to create a real application. The access db with vb code just grew to a point of justifying the need for a real application.

In one sense I'd rather keep the access db because it could be used outside the application for maint and reporting type actions. Plus not having to recreate it would be faster (or maybe not?).

We have a done a requirements driven UML design to capture what this app will (and will not) do. UIT and UAT are absolutely going to be implemented.

But my real attention is on the data store and making sure I make the right decision now.

[~s.o.s~]

In case it has been already decided to phase out the old data storage mechanism, you need to give us a bit more detail as to the nature of your application. Does this new face lift also involve making the entire logic distributed or would it still be a desktop single user application? What kind of database activity is you application expecting? Is the application installed for multiple users? If yes, is there any data-syncing activity which takes place for your application?

BTW, for a single user desktop application any server-less database engine like H2, Derby etc. should be good to go.

[pnelsonsr]

It will be a local desktop user application. No central DB activatey or data syncing.

[~s.o.s~]

In that case any server-less (embedded) pure Java database (read H2, Derby etc.) should work out well for you, unless of course you are looking to make a move away from relational databases. Just be careful when porting queries.