Database Support On Xbox 360
by Chip Lambert · in Torque X 2D · 02/27/2008 (5:29 pm) · 4 replies
Hey guys I just got a Creator's Club membership and have a quick question about the use of databases on the 360.
Is it possible to use an Access database on the 360? I'm working on an RPG that is mainly going to be single-player. I won't lie, I'm aiming at releasing it on the Xbox Live Community games service when it comes out. Would the Access database use work? I'm not sure what all is available on the XNA/.Net framework on the 360.
Thanks.
Is it possible to use an Access database on the 360? I'm working on an RPG that is mainly going to be single-player. I won't lie, I'm aiming at releasing it on the Xbox Live Community games service when it comes out. Would the Access database use work? I'm not sure what all is available on the XNA/.Net framework on the 360.
Thanks.
#2
02/28/2008 (7:28 am)
Makes sense. All I'm wanting to do is store PC information and the such. On Windows I'd used SQLite, but since you can't use external dll's I thought maybe Access would work natively. XML would work by all means, I'm just 1000 times better with SQL than I am XML :). 
#3
Give objects a record number; let the first record in the file be the record length (eg: 200 bytes). Each record can have a start record identifier such as * if this is the last record for the object or # if the object spans into the next record (which would mean if record #10 spans two slots there wouldn't be a record #11 - the next object would be record #12)
To find an object's data in the file just jump to byte (recordNum * recordLength) and read (recordLength) bytes. If the first byte is * then you have the whole object. If it is # then read (recordLength) bytes again. Repeat until you find a record with *. You could even use the BinarySerializer to make the reading/writing easier, and the indicator method allows you to store objects that exceed the record length. (You should still pick a length that allows most objects to fit inside one record).
This is basically how a database engine works anyway - indexes point to a row number within the data file so once you've looked up a row in an index you can jump right to it in the file with a minimum of disk activity, because the rows are of a fixed size. Things like text and blob columns are just pointers from the actual row to a separate place in the file where the columns without size limits are stored.
To create or edit the file you'd need a little utility that could load it into memory and add new records or delete existing ones. To get really fancy you could have a separate index file that contained a Serialized hashtable (dictionary) that associated a name with each record so you can rearrange the file without throwing things off in the code.
03/18/2008 (10:00 am)
If you have a really big database of items that you'd rather not load into memory all at once I suggest using a really simplistic indexed file format (iow a really, really simple database). I've thought of doing something like this, to create a system that can store a lot of data, but be accessed really quickly on an Xbox 360 without taking up much memory. I'd appreciate any opinions on the concept...Give objects a record number; let the first record in the file be the record length (eg: 200 bytes). Each record can have a start record identifier such as * if this is the last record for the object or # if the object spans into the next record (which would mean if record #10 spans two slots there wouldn't be a record #11 - the next object would be record #12)
To find an object's data in the file just jump to byte (recordNum * recordLength) and read (recordLength) bytes. If the first byte is * then you have the whole object. If it is # then read (recordLength) bytes again. Repeat until you find a record with *. You could even use the BinarySerializer to make the reading/writing easier, and the indicator method allows you to store objects that exceed the record length. (You should still pick a length that allows most objects to fit inside one record).
This is basically how a database engine works anyway - indexes point to a row number within the data file so once you've looked up a row in an index you can jump right to it in the file with a minimum of disk activity, because the rows are of a fixed size. Things like text and blob columns are just pointers from the actual row to a separate place in the file where the columns without size limits are stored.
To create or edit the file you'd need a little utility that could load it into memory and add new records or delete existing ones. To get really fancy you could have a separate index file that contained a Serialized hashtable (dictionary) that associated a name with each record so you can rearrange the file without throwing things off in the code.
#4
03/18/2008 (10:05 am)
Nice approach there Russell, one I didn't even think about. 
Associate John Kanalakis
EnvyGames
John K.