Sign in to follow this  
ractoc

Map storing in Database

Recommended Posts

Hello all, I'm currently working on a Map System in Java for creating space maps. The idea is to eventually have a flexible tool to create space maps in a rich client. Now I'm currently working with the idea of storing the completed maps in a database. My question is, how smart is this. Am I on the right track or would it be better to store the maps in flat XML files? The main reason I chose a database over XML (or any other file based format) is speed. It's much faster to search in a database then it is to search a file system and then parse XML files. Drawback would be synchronising the maps with the server since we would need a 2 database setup when we go multi player, one on the server and one on the client, with some way to keep those 2 in sync. I have the basic setup for the database up and running and it's working like a charm, for those interested eventually (when I get to a point I feel comfortable with it) I plan to make the system open source. But only with sufficient support from you guys. No use in making it free to the world if I still end up being the only one working on it.

Share this post


Link to post
Share on other sites
If the data is binary, XML files are maybe not the best choice. But mpipe is right that large files are not the best data for the common relational database systems (Sql Server etc.). While you could technically put a lot of files into a RDBMS, I'd always prefer the filesystem - which is a database on its own.

The filesystem is fast, it can handle added, deleted and modified files efficiently, files can be much more easily edited. Using a DBMS always involves the database overhead plus the actual filesystem access, so it's unlikely that it is faster.

But you can use the best of both worlds: use a relational database to store and quickly access metadata of the files (including their path) and use the filesystem to access it.

It could look like this:

table Files(id, path, type, ...)

table Map(id, name, ...)

table MapFiles(levelId, fileId)

etc.

So you would have a table of all available files and let's say a table with all maps. A third table (MapFiles) would link all required files to a specific map. To load a file, check for its type (to determine how to load) and its path (from where to load). This way your system could handle and index a huge number of files.

Share this post


Link to post
Share on other sites
That's roughly the approach I'm taking now. I use the database for the structure of the maps, the meta data and how all the objects are to be placed on the ma[ (location, rotation, additional properties, 3D-Object file (filename only). That sort of thing. The actual object files to be displayed will be handled in a different layer of the Map System, the Render layer.

Curently the system is setup with 3 layers of which I;m working on the first one: Map storage (working on this one atm.) Map Control, this one will handle all user interaction such as selecting a Map Object and showing the right context menu. And then there's Map Rendering, This layer is responsible for drawing the actual Map Objects to the screen, so this is where the actual 3D-Models would come into play.

The idea behind this setup is that it would be fairly simple to make this either single player or online. In single player all 3 layers would reside on the same client. In multiplayer you would have the storage layer on the server, the render layer on the client and you would have to substitute the control layer with one that can handle the network stuff.

Besides, with this approach, you could always go for the XML variant, just switch out the Storage layer...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this