Database vs. Files ?
Author
Hello!
So I reaced the next step, my graphics is working, my network is chatting ;)
Now I am wondering if I should add in an database to have stuff in, like items, stats and monsters and more
But since I never done C/C++ <-> database, I tought maybe stick to file I/O ?
Whats a good rule anyone knows? For how to decide on database or file I/O.
Author
Thanks it doesnt answer my question tho.
And I tried to DL the windows DLL and link it in project-options
:
-lsqlite3
Maybe I am doing it wrong I havent used DLL files before....
BTW .. Using :
Windows XP & Dev-Cpp 4.9.9
And I tried to DL the windows DLL and link it in project-options
:
-lsqlite3
Maybe I am doing it wrong I havent used DLL files before....
BTW .. Using :
Windows XP & Dev-Cpp 4.9.9
It depends on the size of your project and number of players.
For me > 50 players = database, but if someone has other/better ideas go with them offcourse.
XML is a pretty good alternative especially when you pour a database sauce over it :). It's not as bloated as a database, but has the drawback of getting slow when the number of files grow. All in all there is no definitive answer if we don't know the exact facts&figures.
Open Source XML Database
Apache XML Database
<edit>
Whoops, I somehow missed you needed something c++, (apache has the XML parsers in c++ too, so I guess my point is still valid. It's just an idea though.
For me > 50 players = database, but if someone has other/better ideas go with them offcourse.
XML is a pretty good alternative especially when you pour a database sauce over it :). It's not as bloated as a database, but has the drawback of getting slow when the number of files grow. All in all there is no definitive answer if we don't know the exact facts&figures.
Open Source XML Database
Apache XML Database
<edit>
Whoops, I somehow missed you needed something c++, (apache has the XML parsers in c++ too, so I guess my point is still valid. It's just an idea though.
XML is not a database, believe nothing you hear to the contrary. I would favor a database over any XML method for the sheer sanity of not having to use escape characters to avoid breaking the XML code. XML is very sensitive to special characters (which are actually very common in normal text messages).
Anyway, databases are best for when you have a large amount of data to work with that must support random access and queries. For an online project I would almost always go with a database, but if your project is small then file IO may be adequate. Actually XML may be as well, but I still say that XML is a headache.
Regardless do not fear MySQL, you can learn that in a single day of work and it's free, and it's offered by most web host pre-installed.
Anyway, databases are best for when you have a large amount of data to work with that must support random access and queries. For an online project I would almost always go with a database, but if your project is small then file IO may be adequate. Actually XML may be as well, but I still say that XML is a headache.
Regardless do not fear MySQL, you can learn that in a single day of work and it's free, and it's offered by most web host pre-installed.
Author
ok its not that I dont know mySQL, I work with it every day at work :)
just never tied C++ to it.
Go sqlite3 to work now by building a static library, now I must only figure out how it all works..
Using files (like regular textfiles) and using XML cant be any differant now can it? Other then that I have to write much own code to make some sense of textfiles...
EDIT :
http://weblog.bignerdranch.com/?p=12
He says if more then one person tries to access SQLite at once it all goes crash-boom-bang?
just never tied C++ to it.
Go sqlite3 to work now by building a static library, now I must only figure out how it all works..
Using files (like regular textfiles) and using XML cant be any differant now can it? Other then that I have to write much own code to make some sense of textfiles...
EDIT :
http://weblog.bignerdranch.com/?p=12
He says if more then one person tries to access SQLite at once it all goes crash-boom-bang?
Quote:Original post by T1Oracle
XML is not a database, believe nothing you hear to the contrary. I would favor a database over any XML method for the sheer sanity of not having to use escape characters to avoid breaking the XML code. XML is very sensitive to special characters (which are actually very common in normal text messages).
Anyway, databases are best for when you have a large amount of data to work with that must support random access and queries. For an online project I would almost always go with a database, but if your project is small then file IO may be adequate. Actually XML may be as well, but I still say that XML is a headache.
Regardless do not fear MySQL, you can learn that in a single day of work and it's free, and it's offered by most web host pre-installed.
I didn't call XML a database I just said it can be used as storage for a database. It's not something you would actually want, but maybe, just maybe it can be usefull for a small project were you don't have access to a database.
I also said that it could be an alternative at best a eye opener.
Furthermore, performance-wise, databases don't exist for nothing. They truly are the optimal performance backbone of any commercial system.
Implement the data store as a separate class with a clear interface.
Define the operations you want to make on your data store.
Have the code call the data store, and implement the data store in the easiest way you can think of.
Then, when and if the data store becomes a bottleneck, start optimizing.
However, there's one thing you should think about up-front: both disks, and databases, have latencies in access. Blocking reads is going to kill your main loop. Thus, the ideal interface to the data store is of the form "start a request" that then completes (with the result) sometime later.
An alternative, if you don't want to use the annoying request pattern, is to either put the processing of each separate thing inside a fiber (which costs stack space and context switching), or pre-loading all data into RAM on start-up, so you can immediately answer any questions.
Define the operations you want to make on your data store.
Have the code call the data store, and implement the data store in the easiest way you can think of.
Then, when and if the data store becomes a bottleneck, start optimizing.
However, there's one thing you should think about up-front: both disks, and databases, have latencies in access. Blocking reads is going to kill your main loop. Thus, the ideal interface to the data store is of the form "start a request" that then completes (with the result) sometime later.
An alternative, if you don't want to use the annoying request pattern, is to either put the processing of each separate thing inside a fiber (which costs stack space and context switching), or pre-loading all data into RAM on start-up, so you can immediately answer any questions.
There are mainly three types of data in a game (other then graphic information), yes this is not really true, there can be a lot more but trying to make this simple.
1. Static game information (stats of bad guys, locations, treasure stuff)
2. Player and game play information, stats, equipment, items, kills..
3. Save game information, kind of all of the above. Not time dependent.
Static game information is loaded when either the game loads or when a area loads. File formats can handle this information pretty easily. The data can be seqiental and easy for file i/o to handle.
Player and game play information changes all the time. In single player games you can store this information in memory. For a large multiplayer game you might wand to store in a database to allow a person to come back if they drop a connection. Databases are good here for multiplayer games because of the large number of transactions and the random nature of the transaction.
Save game information is much like loading information, it can be writte and read sequientaly and is not as time dependent. So database is not needed for this kind of information.
Now with all that said, if you impliment a database for number 2, then you should use a database for the rest. Best to keep all your information in one format.
theTroll
1. Static game information (stats of bad guys, locations, treasure stuff)
2. Player and game play information, stats, equipment, items, kills..
3. Save game information, kind of all of the above. Not time dependent.
Static game information is loaded when either the game loads or when a area loads. File formats can handle this information pretty easily. The data can be seqiental and easy for file i/o to handle.
Player and game play information changes all the time. In single player games you can store this information in memory. For a large multiplayer game you might wand to store in a database to allow a person to come back if they drop a connection. Databases are good here for multiplayer games because of the large number of transactions and the random nature of the transaction.
Save game information is much like loading information, it can be writte and read sequientaly and is not as time dependent. So database is not needed for this kind of information.
Now with all that said, if you impliment a database for number 2, then you should use a database for the rest. Best to keep all your information in one format.
theTroll
EDIT: *whoa, totally missed that you got it working and were using it. Sorry man. Typically you won't have multiple programs running off the same database file on the same computer in a standard game, but what do I know about your project?
Let me re-direct you to sqlite
It is a nice solution for these reasons:
1. it has no external database program to set up
2. it's small and simple to integrate in a project
3. did I mention you don't need to install mysql on the client's machine to use it?
Essentially it's a database that you can roll directly into your project without dealing with an external server database such as mysql. It uses similar syntax to query, and is generally a graceful solution which should be flexible enough for most uses.
Let me re-direct you to sqlite
It is a nice solution for these reasons:
1. it has no external database program to set up
2. it's small and simple to integrate in a project
3. did I mention you don't need to install mysql on the client's machine to use it?
Essentially it's a database that you can roll directly into your project without dealing with an external server database such as mysql. It uses similar syntax to query, and is generally a graceful solution which should be flexible enough for most uses.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
