[gameprogrammer] Re: sqlite example program
- From: Alan Wolfe <alan.wolfe@xxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Sat, 22 May 2010 07:33:17 -0700
I'll throw my 2 cents in...my background is 6 years web/database dev, 3
years professional game development.
Accessing a database is slower than using internal arrays to your program,
but a good DB engine (and a well tuned db) will reside in memory and
accessing it will be faster than accessing something from disk because it's
smart about what it keeps in memory. This is how a db IS faster than file
access.
Some benefits of using a database:
* You can easily change data while your program is running
* Other technologies can easily interface with the database, such as PHP if
you want to make a community website for your game which shows live updates
* Importing and exporting data is extremely standardized
* Many database servers have advanced features such as database replication
where you can have a database on multiple servers that are kept synchronized
* Non engineers have a higher probability of either being able to work with
databases, or more easily being taught how to use tools which interface with
the database
* It's easier and cheaper to find database hosting than it is to find your
own custom c++ server hosting.
* You can find or buy really mature and sophisticated reporting programs
(such as crystal reports) to interface with the database and generate
reports that can show you trends or other meaningful things.
Like i was saying above, accessing a database is far slower than reading
data out of internal datastructures to your program though. While a
database can be very fast, there are a lot of layers of processing between
making a request of "select userid from users where username='josmith'" and
where it actually returns you the data.
In game programming, cpu cache misses (where the cpu fetches values from RAM
instead of it's own internal cache) are often too expensive, so looking into
a database for data is just right out wayyyy too slow.
Because of that, you aren't going to store any real time data in a database
such as enemy positions or enemy life or anything like that, but some good
things to store in a database for your game may be login credentials, user
account information, data that you've logged from in game and things of that
nature.
On Sat, May 22, 2010 at 4:31 AM, Ethan Grammatikidis <eekee57@xxxxxxxxxxx>wrote:
>
> On 22 May 2010, at 06:56, Chris Nystrom wrote:
>
>>
>> SQLite seems to be far more trouble to use than simply creating
>> arrays. I assume that as you scale up though, it is important for
>> performance to have an actual database instead of internal arrays of
>> data. Is there a rule of thumb about when you should use a database?
>> Or is there some other reason to use SQL besides performance with
>> large systems?
>>
>
> I've just begin a very long project to gather data on just this sort of
> question, just when where and how is the right way to use each available
> technology. An inevitable side effect will be finding out if some
> technologies are worth anything at all.
>
> As to SQL itself I haven't anything definite yet, just an impression that
> for a straightforward key:value mapping it may not be worth using at all.
> Filesystems provide key:value as name:file, and am I right in thinking that
> file access is generally faster than database access? Last I heard (about a
> year ago) MySQL was much higher performance than SQLite, and I don't think
> MySQL can't match speed with a filesystem lookup. (How can it, when it uses
> the filesystem as a backend anyway?)
>
> --
> Simplicity does not precede complexity, but follows it. -- Alan Perlis
>
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>
Other related posts:
