Is that a good thing? I see everyone using MySQL but personally SQLite was much easier to develop with (I have experience with it from game development).
Also, my belief in that SQLite can be faster as it doesn't depend on internet speed + less money on additional host.
Just wondering though if there's some hidden variable I should know about and if I did the right thing.
If I need an UCP I will upload both the server and forum on the same VPS service.
#I started to develop an RP server using SQLite, is that ok?
5 messages · Page 1 of 1 (latest)
The main deciding factor is CPU time, not latency. SQLite runs synchronously on the server thread and while it is performing its operations, nothing else is happening, not even player sync.
SSDs have gotten very fast, but disk IO is still quite slow. Doesn't matter so much for a web application where the user can wait a second for a result, but in a fast paced game this is extremely important.
And oh, a MySQL server should always be on the same local network and ideally on the same server, otherwise it also becomes quite slow. Though you won't have the sync problem mentioned earlier due to the queries executing on a different CPU thread.
I see. The reason I started with SQLite is because it's pretty much plug and play, no additional setup + familiarity with it from web dev. I timed my queries just so they are exected once, when the player connects (loads his data) and when disconnects (saves his data). Other read/write queries run solely on specific commands. I guess it's optimized if I did it like that?
The general consensus nowadays is to save important data as soon as it changes. If the server crashes, OnPlayerDisconnect is not executed and players may lose hours of data.
You also can't really time queries on a empty database, you need a quite sizeable database to test this and the query optimizer might choose a different query plan depending on the size of the data. It's not unreasonable for a query to take like 50ms, which is already quite noticable.