I dont get what your problem is exactly...
You have a database that contains all your weapons and stuff... so like:
{Weapons Table}
id - int
name - varchar(30)
type - tinyint
power - smallint
Then when you have a user run your game it calls the DB (be it directly from your app or from another layer) and returns the data... am i right up to this bit?
If so are you just wanting to cut down on calling the DB whenever you want a weapon if you already have it loaded or something?
You sound like you are always loading in EVERY weapon, and usually you would only make a call for weapons based on an individual ID or based on some other criteria... like all weapons owned by a player (which would be something like)
SELECT * FROM weapons
JOIN players_weaponsON weapons.id = player_weapons.item_id
WHERE players_weapons.player_id = @YourPlayerID;
If you could explain your scenario a little more then i could possibly advise you a bit better...
If you are doing some sort of admin system and want to load in all weapons then you can either bring them back in chunks so lets say 0-50, 51-100 etc (a LIMIT clause if in MySQL), or you can just bring them all back when the user loads the weapons section... it may sound like its alot but if you have a simple weapon model like described above it would use next to no memory:
id (int) - 4 bytes
name (string) - i think its 2 bytes per character as its unicode (could be wrong)
type (byte) - 1 byte
power (short) - 2 bytes
That is a total of 7 bytes (Excluding string data), so lets say the average name is 10 letters long your average object size in this scenario would be 27bytes... so if you have 1000 of them in memory it would be 26.5kb (roughly) which is nothing... and if you only do it once then just keep it in some generic storage... like a dictionary keyed on the id or something it would yield fast lookups and simple data storage.
You can alternativley try to sort your data before you bring it back, so ask the user if they want to sort by chunks/type/power/value etc then just limit the stuff brought back...
If however you are doing this on a client side system, like your in-game stuff you should NEVER need to bring back all weapons at once as there would be no scenario when any one user would need to know of ALL weapons at any one time... if you are however having some sort of shared backend that caches all weapons or something then maybe you could look into Memcached or something which would give you a distributed caching system that would easily churn over hundereds of thousands of rows in storage without any worries...
One final thing that worries me is that you mention that the clients could change your *static* data models... by static i mean models that come from the DB but dont get updated, so areas, skills, items. A user may have many items but it can never change the items, only the amount of them that it owns. Whenever a user does do an update be it to their position or equipment etc the client should rarely do the work (im assuming you have a multiplayer system or at least a single player game that is driven from a DB/server layer), they would shoot over their update (like ive moved right) the server would then verify it, and if its correct it would insert it into the DB itself and send the client a true response or similar. So even if the user did some hack to change their level to 100 and HP 2000 and moved themselves 1000 pixels to the right, the server would laugh at them because its invalid compared to the servers snapshot.
Anyway im just rambling and most of it is probably not useful, if you can narrow it down or give us a scenario... pm me if you dont want to post publicly and i can try and help...
