Conceptual Table Size Problem

Let’s say I’m using Azuisleet’s threaded MySQL module (TMySQL) to store player information, such as their bans, inventory, indexed by Steamid.

Since it is threaded, I can not access information on-demand. The most feasible workaround is a table that acts like a cache. Whenever a request comes through, or I anticipate a request coming through, the TMySQL immediately sends the information to my cache, where It can be used by other functions.

Over time, this table could grow quite large, since I would need to definitely cache players if they join the server, as well as if, say, an admin wanted to access some records. Would I ever run into the problem where the table is so big that it becomes inefficient, or overflows? (Of course the table would empty if the server crashes, and the cache would start from scratch again.)

I don’t see any reason you would need instantaneous access to the data.
Simply design your systems to work with callbacks, instead of instant returns.
i.e: When querying the information of a player: freeze him (and block his command with SLog) until the data has been returned.

When an admin queries for player information, send them the size of the table, then have them send their current scroll possition. Using this, use datastream or usermessages to send the information as they look. If there’s a search field, have the query be sent to the server and return the results in a similar manner (with scrolling).

It’s entirely possible and feasible, you just need to get it right.

If you need help, add me on Steam: DecoDaMan

(Akwardly sent from my iPhone)