Game object persistence
Author
I''m working on a MMOG, and can''t really make up my mind when it comes to technology choice for persistence of players.
I''m considering both SQL and XML (Or maybe a mixture of the two?)
Using pure SQL I would have a player object spread over multiple tables - and the structure of objects (like inventory items, equipped items, spell affects etc.) would force me to use more than one SQL statement - even recursively performing SQL statements with containers inside containers.
With XML I would have the advantage that everything I need to read is in one file, and I expect this to be faster than performing multiple SQL statements? (At least with SAX parsing, of course then I would have the added complexity of maintaining stacks for nested elements). Problem is that to locate a player I need to locate the file - and open the file just to get the password.
Using mixed SQL/XML I would save attributes of the player in an RDBMS, while structured / variable length data could be saved as XML in text type fields.
Any comments on which method to choose?
***
For Java games and Java related resources, go to http://www.javaengines.dk
***
I really doubt that XML would be faster. It''s a great format for storing and porting data from one system or program to another, but you don''t want to use it for anything performance-critical.
It''s basically for storing data in a simple and standardized format, so that you, or someone else, can load or edit it without too much trouble. It''s not made for efficient manipulation, which is pretty much what databases and sql is all about.
First, plain text isn''t exactly the most compact format, so you''ll get tons of overhead just from that, and secondly, you''d still have to locate the data you need in multiple places in one or more files, basically requiring you to implement your own database, using a unoptimized storage format, and starting completely from scratch on the database access and manipulation system. The alternative is to use a "real" database, with optimized data format, and an optimized management system.
You can do a lot of complex queries in sql, including subqueries in different tables, and in most cases, you won''t need more than one (complex) query. In cases of recursion, you''d have a slight problem though, and would have to perform multiple queries, so you should try to avoid those when possible. But provided you have a good graps of database tuning, they''re pretty damn fast, actually, and far faster than manually opening files and finding what you need from there.
Look at simple php/mysql websites, running on average computers, and can *still* serve hundreds of requests at a time. And that''s even though php is horribly slow, and the sql queries generally are very clumsy and unoptimized.
Now try making a program that opens an XML file, parses it, and then loads a similar amount of different data from different locations in the file.(most likely, you''d need multiple files as well). I guarantee you, it won''t be fast.
---------
Life is like a grapefruit. It''s sort of orangy-yellow and dimpled on the outside, wet and squidgy in the middle. It''s got pips inside, too. Oh, and some people have half a one for breakfast
It''s basically for storing data in a simple and standardized format, so that you, or someone else, can load or edit it without too much trouble. It''s not made for efficient manipulation, which is pretty much what databases and sql is all about.
First, plain text isn''t exactly the most compact format, so you''ll get tons of overhead just from that, and secondly, you''d still have to locate the data you need in multiple places in one or more files, basically requiring you to implement your own database, using a unoptimized storage format, and starting completely from scratch on the database access and manipulation system. The alternative is to use a "real" database, with optimized data format, and an optimized management system.
You can do a lot of complex queries in sql, including subqueries in different tables, and in most cases, you won''t need more than one (complex) query. In cases of recursion, you''d have a slight problem though, and would have to perform multiple queries, so you should try to avoid those when possible. But provided you have a good graps of database tuning, they''re pretty damn fast, actually, and far faster than manually opening files and finding what you need from there.
Look at simple php/mysql websites, running on average computers, and can *still* serve hundreds of requests at a time. And that''s even though php is horribly slow, and the sql queries generally are very clumsy and unoptimized.
Now try making a program that opens an XML file, parses it, and then loads a similar amount of different data from different locations in the file.(most likely, you''d need multiple files as well). I guarantee you, it won''t be fast.
---------
Life is like a grapefruit. It''s sort of orangy-yellow and dimpled on the outside, wet and squidgy in the middle. It''s got pips inside, too. Oh, and some people have half a one for breakfast
Author
As I understand it, complex queries or not, the rows of a resultset will all be tuples of the same length containing the same types ? If im wrong, please correct me - but if that is the case then I can''t avoid performing multiple queries.
With xml I could just read everything I need for a player in one go from a single file (Or a single database field if I use the 3rd option).
With xml I could just read everything I need for a player in one go from a single file (Or a single database field if I use the 3rd option).
I'm a big fan of XML, but only use it for things that get loaded in batches. for other, lookup type things toss it in the DB for ease of lookup/search.
So, what I would do is store the user's account info and stats (ie. how much money they have) in the database. These are things that probably have to be queried and updated often. Anything else, such as the contents of their inventory that only gets saved during a save operation for example can go in XML for ease of data structure management. The database can store the location of the XML document, or even the document itself (that one's up to your personal pref).
-edit: oh, and multiple SQL queries aren't a big deal if you can batch then, or put them in a stored procedure. You can just return multiple resultsets of whatever you need, or if the data lends itself to this, just join it all up into one row.
good luck,
Joel Martinez
http://www.codecube.net/
[edited by - joelmartinez on March 5, 2004 1:23:20 PM]
So, what I would do is store the user's account info and stats (ie. how much money they have) in the database. These are things that probably have to be queried and updated often. Anything else, such as the contents of their inventory that only gets saved during a save operation for example can go in XML for ease of data structure management. The database can store the location of the XML document, or even the document itself (that one's up to your personal pref).
-edit: oh, and multiple SQL queries aren't a big deal if you can batch then, or put them in a stored procedure. You can just return multiple resultsets of whatever you need, or if the data lends itself to this, just join it all up into one row.
good luck,
Joel Martinez
http://www.codecube.net/
[edited by - joelmartinez on March 5, 2004 1:23:20 PM]
Author
The way you describe it is actually exactly the 3rd method I was describing. I just wonder what will be fastest - storing a filename or the xml itself?
I still haven't really decided yet - if I want to be able to query inventory items on characters I need to use SQL for everything.
[edited by - blackone on March 5, 2004 1:36:13 PM]
I still haven't really decided yet - if I want to be able to query inventory items on characters I need to use SQL for everything.
[edited by - blackone on March 5, 2004 1:36:13 PM]
Rather than using SQL you can still use XML and get the best of both worlds. You can use XML as a database and use the latest XQuery (fully Microsoft product supported - you can embed them in HTML pages) at http://www.w3.org/TR/xquery/ to perform your queries. There''s an opensource initiative at http://exist.sourceforge.net/ to form an XML database manipulation library.
See if it fits your needs...
See if it fits your needs...
quote:Original post by blackoneI''ll be honest, in your situation, I''d probably just store everything in the database. Recursive patterns arent too tough to implement in a relational database. If you need help, just look for information on implementing message boards with nested response threads. Should be the same concept
I still haven''t really decided yet - if I want to be able to query inventory items on characters I need to use SQL for everything.
Joel Martinez
http://www.codecube.net/
If setup properly, it is possible that table resulting from your sql query will contain everything you need so you only have to make a single query. I''m not sure its more efficient though - to know that, you''d have to time the various possibilities.
You just need to know how to properly setup one<->one, one<->many, and many<->many relationships in a database.
Just remeber, databases are MEANT to be fast. Its been a goal for a very, very long time of database designers to make them fast. XML is meant to be portable and easily editable. If you''re looking for speed, databases are probably going to come out on top (but again, you''d have to time it to be sure).
You just need to know how to properly setup one<->one, one<->many, and many<->many relationships in a database.
Just remeber, databases are MEANT to be fast. Its been a goal for a very, very long time of database designers to make them fast. XML is meant to be portable and easily editable. If you''re looking for speed, databases are probably going to come out on top (but again, you''d have to time it to be sure).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
