Quote:
Originally Posted by WhiteDragon
I think this is a little overly general.
To refine it a little for anyone who is interested: - Indexes are stored in memory. This means that looking up the rows you need will be fast, only reading it after finding it will be slow.
- But, even reading the rows won't neccessarily be slow either, since SQLite keeps a cache of a bunch of rows in memory at all times. When reading hot (frequently/recently accessed) data, it'll be from memory.
Similarly, writes are done into memory, and the way Graal's SQLite stuff is set up is that it doesn't wait to write to disk before returning. So a write will just take as long as writing anything into memory.
But even with this, if you need the guarantee that something will be in memory, it's a good idea to keep it in a regular ol' client variable since you may not want the lag if the data is cold and its needed for something important (e.g., sword strength or something which needs to be there in real time).
But yeah, complexity. It may not be worth all this. |
Then what would one use a SQL lite database for? It's starting to seem like a lost cause due to performance issues. Then again this does guarantee secure data storage and manipulation. I believe this is due to SQL transactions actually locking the DB table before writing to avoid overwriting.
Hopefully if I keep this simple and everything organized it will all fall into place.