[Edwin Stang]

why hsqldb? (http://hsqldb.org/)
- its a sql database in a file
- it seems its well integrated to java (written in java), atleast better than sqlite
- its quite fast compared to other similar tools

pros:
- i think being able to use sql queries on the gamedata would make things a lot easier
- also it would save ram coz the data is always gotten from db file (no more object caching) -> better scalability when gamedata grows
- more flexible -> sql allows us to find interesting information more easily -> coz sql is not as complex as direct xml reading
- another new fun thing to learn :)
- instead of writing a junit test for current gamedata we could write it along when we test the new code anyway (instead of writing all those temporary test code snippets)
- gamedata.xml would only be processed when a new version of it is published by us, then shipped to the user as a db file
- user wont be able to mess around with gamedata.xml

cons:
- we need to create a table layout that suits the xml file dtd
- structural changes will involve 4 (xml, db layout, xml to db parser, gamedata) modules instead of 2 (xml, gamedata)
- we cant be sure if the new setup will really be worth it, though in my eyes we should try

why not remove xml file?
- simple, gamedata should be still easily editable without the need for a tool!

how would the setup look like?
- the db will be a cache for the xml, this means we need:
-> an xml parser that runs through the whole xml file and puts all the data into the db (would be a tool not shipped with releases)
-> new gamedata classes based on sql which would look similar to server database.java
-> the db file
-> the xml file
- releases should ship with prefilled gamedata db files, so there is no need for code to create the db structure etc (though we have to see how this worx)
- i think it would still make sense to split the queries we have into different classes like we have atm
-> we have to decide if we go for the same setup as we have in server (player calling a database class for queries)
or if we split the queries into different classes (let the Room class do queries itself)
-> i would like to vote for Room having sql queries, though we have to see how well this would work,
because on server we first used a sqlhelper class which abstracted the db connection etc, but this was inflexible and did not allow us to do sql parameter validation
-> maybe we can use a connection helper now, coz we dont need validation on a readonly db
-> though it doesnt have to be readonly, coz we could implement "last used" settings for room creation etc with this setup and other things more easily

for more reading on the topic, search for xml vs hsqldb
or read the comments from this webpage: http://radio.javaranch.com/gthought/2004/03/23/1080079087000.html

I would like to hear your opinion about this

hmm while i think about it, the xml file and parser could be aswell removed, maybe it is a better idea to store the initial gamedata in an sql insert script

or maybe there already is both a tool for generating a sql layout from a dtd and to generate inserts from an xml, so this wont need to be created by us ... have to search a bit ^^

well, its easy to find database to dtd, though the other way around doesnt yield any quick results

maybe another alternative approach would be to search for a way to run sql queries on xml files :D

ok, using sql directly on xml is impossible (atleast from java as .net has LINQ), but there is XQuery which has something similar to sql, is it worth to learn this language?

xquery seems to be conceptionally made for websites

i would rather prefer using good old sql

what about object oriented databases?