Simple Data Storage

[CarrotTop]

I'm trying to create an application simply to store my DVD collection (as a test app).
This is my first application that will actually be using "data"... there's a lot of options available but... none really seem that great...
Plain text is slow for pretty much everything and requires you to write a manual parser
XML seems to be bad for reading large files and inserting and deleting records.
Databases require you to distribute extra programs with yours that actually manage the database access and all this seems excessive for something I just want to be able to send the app to someone and let them run it...

What is the right kind of way to store the DVD records for something simple like this? Should I be looking at SQLite and just cave in on distributing the JAR with my app?

I guess I'm most interested in what kind of approach is "right" for a pro Java developer.


Thanks

[JosAH]

If your CD collection isn't humongous (< 10,1000 CDs) you could use Serializable objects in some sort of a Map. When your application starts it reads in (deserialize) the entire Map from a file, do your things with the Map and serialize it again just before your application stops. For all other purposes I'd use a database system of some sort.

kind regards,

Jos

[JeffGrigg]

A relational database would be considered most "professional."

I would seriously consider simply serializing all the state to a file. For added safety do the "rename" trick: (1) serialize to a '.new', (2) delete '.bak', (3) rename '.db' to '.bak', (4) rename '.new' to '.db'. Where 'name.db' is "the official saved state."

Personally, I would consider Prevayler | Download Prevayler software for free at SourceForge.net but then I am kind a of a rebel. (Darn; the main site http://www.prevayler.org/ seems to be down at the moment.)

[Tolls]

The drawback with serialization is, if you add some new fields to your classes then the existing serialized data is unuseable.

As for a DB, Derby comes with the JDK and is a single extra jar file to distribute with your program. It runs embedded as well.

[JeffGrigg]

The drawback to using a relational database (or XML or anything else) is that if you add some new fields to your classes, then you'll have to add them to your schema, and deal with upgrade issues. These are fundamental issues. You'll have to deal with them with a database or serialization or any other technology you may use. It is possible to address these issues with all of the technologies, including serialization. So don't let that be too big of a concern.

[Tolls]

Except that with the database you can still read in the data.
Conversion scripts are a damn site easier to write than attempting to convert an old serialised dump to a new set of classes.
We do it here all the time.
If I add a field F to my class C then I cannot read in the data from the pre-F serialised file. I can, however, still read in the data from my database.

[Tolls]

Just to expand on what I just posted.
If I have this:

public class C implements Serializable {
   private int E;
... some other code ...
}

and I serliaze this to save it at some point.

If I then change it to this during development:

public class C implements Serializable {
   private int E;
   private int F;
... some other code ...
}

then my "saved" file is now not useable. I have lost that data. The only way to get it back is to use my old code to read it in and provide some way of saving it as text (say), then writing a parser to read it into the new code and then serialize it from there.

If I had saved it to a db then:

CREATE TABLE C (E INT);

gives me my initial table.

And for the change:

ALTER TABLE C
ADD COLUMN F INT;

gives me my new column, because I can change the structure of the saved data.

Serialization is a means of transmitting data...it really isn't terribly good as a way of saving state because it doesn't handle change.

[Tolls]

And...does anyone else have problems typing serialize?

[JeffGrigg]

@Tolls, you do serialization all the time? And you don't put use serialVersionUID in your classes? If you did, adding and removing fields would be handled automatically. It's possible to support versioning with serialization. But I'll admit that it does require discipline and planning.

Discover the secrets of the Java Serialization API

[Tolls]

I do database scripts all the time.
Serialisation remains where it is supposed to be...as a means of transmitting data, not for storage.
And we do use UIDs.

[kjkrum]

I've messed around with ObjectDB a little bit. It uses JDO and/or JPA, although some of the annotations do nothing because it's not a relational DB.

The cool thing about it is that its Persistence.createEntityManagerFactory(...) can use a file name as an argument. So opening a DB in your app can be as simple as using a JFileChooser.

It's a commercial product, and I'm not sure what the licensing requirements are for distributing it with your app.

[CarrotTop]

I think I'm going to be going with a database and Derby looks appealing... Does anyone have a good tutorial that'll take me through just the bare minimum to set up a simple application that stores information in one of these databases? :) Everything I find seems to be extremely involved :)

EDIT: Also... preferably with reference to distribution... I want to know what other users are going to need to run the program, if anything.

[Tolls]

Is the Getting Started too involved?
Actually, looking at it it might be.
There's a good section in it, though, on using the embedded driver (which is what you probably want) in a Java program.
This bit here.
That'll get you up and running with a database.

For distribution you'll want to read up on defining exactly where it deploys the db. I use the user.home property to get the home directory, then create a ".myapp" under which will be my derby db. That would go in the "subsubprotocol" part (which is a rather silly name looking at it).

Something like:

String connectionURL = "jdbc:derby:" + System.getProperty("user.home") + appDirectoryName + ":" + dbName + ";create=true";

where appDirectoryName is the .myApp, which you'll have to check whether it exists.