Read Only Databases SQLlite or MySQL or a procedurally generatd code file

[133794m3r]

Ok, since i've not really looked at sqllite that much but it says that its only limit is the read speed of the HDD. Now i personally beleive that this is quite a bit faster than mysql's read speed. Since this is going to be done via a read only database type of thing ie the constants database.

Since it is supposedly really fast for read only transactions.

[Chris]

If you want pure read only (no clue what for) then performance would be in that order:
- previously procedurally pregenerated code file
- NoSQL (not sure, but I heard they designed it for this)
- MySQL (MyISAM)
- MySQL (InnoDB)

"but it says that its only limit is the read speed of the HDD" - They lied At least for complex querries where you have to search through millions of entries on a complex criteria and then sort it via order by followed by grouping of similar results
But yeah, if you have one table with one entry then the limit is the speed of HDD. As in any other database

[133794m3r]

If you want pure read only (no clue what for) then performance would be in that order:
- previously procedurally pregenerated code file
- NoSQL (not sure, but I heard they designed it for this)
- MySQL (MyISAM)
- MySQL (InnoDB)

"but it says that its only limit is the read speed of the HDD" - They lied At least for complex querries where you have to search through millions of entries on a complex criteria and then sort it via order by followed by grouping of similar results
But yeah, if you have one table with one entry then the limit is the speed of HDD. As in any other database

remember previously about making a procedurally generated code file which was supposedly 'like a cache'  type of thing. Since the items and other such 'constants' won't be changing within teh game world except when there's a content patch/expansion coming down the asset pipeline, so i see no reason in using a bottleneck when none is needed. And it wasn't going to be 'search by order' or any other thing. It was mostly just going to be 'go get this stuff' like if it was a loot table it'd just go get all of the values in teh loot table with the primary id of <insert whatever> and it'd hold those items, amounts and probabilities for later use when someone attacks the thing or well harvests it. The other part of the equation things like logs, chats etc are going to be an entirely different database on development and also live servers since i see no reason in doing additional queries on thigns that won't change more than once a month if that on the live servers.  I guess the just procedurally generated code files will be best, especially for the loot tables since they will have probabilities and some other things.

[Chris]

Oh, you mean stuff like one table one entry holding settings. From practical point of view I would say, forget it, other things will kill the server far before this had a chance to affect it. With one static entry the odds are it will be always cached and served from memory (not sure how exactly cache works, but that's the most logical option) also any differences between any storage engines/DB types would be meaningless. From theorethical point of view I would say, go for pregenerated setting file.

[133794m3r]

Oh, you mean stuff like one table one entry holding settings. From practical point of view I would say, forget it, other things will kill the server far before this had a chance to affect it. With one static entry the odds are it will be always cached and served from memory (not sure how exactly cache works, but that's the most logical option) also any differences between any storage engines/DB types would be meaningless. From theorethical point of view I would say, go for pregenerated setting file.

er... no, i meant one table all of the various 'settings' so to speak since all loot tables are is a list of values that come up when a random numberis generated for it. It's going to be all of the loot tables and other such things. The thing itself is going to be how many ever values that there is. My only concern with using the code file to sort them is ram consumption during runtime. Also i was going to do it instead of having to have multiple databases for the static data since thus far there's going to be unstable(constantly changing as the day/hour goes on)->testing(it is what it says)->stable(simple enough). So thus ifi was going to use databases for it, i'd have to have an extra 2 databases alone.