tags:

views:

114

answers:

6

The assigned homework problem needs a function to store a user-selected video game. This is a small school project, and I was wondering what would the best way to store the information. The program must access the video game bookings, but I think a database is a little overblown for such a small task.

What would you do?

+6  A: 

Usually, for small school projects, I invent my own flat file format.

Usually it is a simple CSV-like file, with some key-value pairs of some sort.

Depending on the type of information you need to save XML may be the way to go.

Also, if the information only needs to be saved for a short period of time (One run of the application), and amount of data being saved is relatively small, simply keeping all of it in memory will most certainly make the program much faster, and usually easier to write.

jjnguy
I'm with jjnguy. This is only a school project and the OP is correct in that using a database is over the top; flat files are great for this kind of thing. You might want to check out Berkeley DB for this kind of thing too; You can serialize your objects into a persistent map using it.
Adamski
+6  A: 

Kai's right, although a good way to manage 'bookings' info of video games would still be a small database (try sqlite). I'm sure you'd want to associate bookings info with a user and so any sort of relationship would also justify the use of a database.

While text files of various kinds might work I reckon it's so little extra effort to use a DB I would do that.
djna
HSQLDB and SQLite are pretty easy to set up and use; I'd also suggest using a database. If you use flat files for this project, you'll probably just end up implementing something akin to a database anyway, with a flat file for each table--you just won't have the nice API and query capabilities that are provided by a database.
rob
A: 

It depends on what kind of data are you talking about, how much of data, how you will be accessing and presenting the data and whether you might need to do any further query and analysis of the data.

I would say CSV or SQLite.

Langali
+1  A: 

It could be helpful if you were a little more specific but...

I think what the assignment is trying to get you to do is understand that the program will not know the data types and the size of the data (row and column wise) until runtime.

From what you're telling me, I would try modeling a table through a mutable list. Program it generically so you can swap out the implementation:

List> table = new ArrayList>();

Is this just video games? If so, I would create a VideoGame object, store fields such as name, maker, system, etc, and put it into a mutable data structureand wallah! It all depends on your operations you will be performing on the list...are you searching and sorting? Do you care about retrieval times?

If you want retrieval to be O(1), or in inaccurate laymen terms, "about one instruction," consider using a Map. If the key is a video game's name, it will return in O(1). If there are multiple entries, consider using a List as the value.

I hope this wasn't too long and confusing but please specify if the number of fields is known or if it has to be entirely generic. If it has to be entirely generic, just use a database! It's made to be generic...or if you really don't want to do that, use the first method I've described.

Hope it helps.

vinnybad
+2  A: 

I think the easiest solution is to serialize the object that holds your data, then write to disk (choose whatever file extension make you happy). Simply read the file and you've got your object back!

FileInputStream fis = new FileInputStream(filename);
ObjectInputStream in = new ObjectInputStream(fis);
Foo f = (Foo)in.readObject();

Here's a great primer on the whole process: Discover the secrets of the Java Serialization API

perimosocordiae
Very easy to make your life difficult for your future self with serialisation.
Tom Hawtin - tackline
True, it's not a "real" solution at all, but it works really nicely for limited lifespan projects (read: school projects).
perimosocordiae
Why would it make things diffiucult by using serialization?
GeoffreyF67
+1  A: 

Create your own text file (CSV etc)
Pro: Easy to edit
Con: You have to do all that marshalling yourself. And make up the file format. You will likely end up with a badly written database. Done badly changing the objects could be a real pain.

Serialize the objects (in either binary or XML)
Pro: Something else handles the marshalling (build in with binary and XML if using "beans")
Con: Changing between versions of Java could break a binary formatted serialization. XML requires beans.

Custom XML file
Pro: XML is well supported in Java
Con: You will likely end up getting scared by existing marshalling APIs and rolling your own (using the Java XML APIs one hopes). Then you end up in the same space as text files (a badly written database).

Embedded Database
Pro: SQL is sexy.
Con: Unless you already know SQL and/or are using an ORM product ORM can be a bit of a pain.

I'd likely go embedded database + JPA.

mlk