Video game bookings datastore [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, referen开发者_运维知识库ces, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

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?

---

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.

---

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.

---

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

---

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.

---

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.

---

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.