Asheras wrote on Sep 6
th, 2017 at 9:09am:
On the topic of TR cache. Here is what I suspect they do: (No actual knowledge of their DB Structure)
[...]
The difference is that if they store the items in different tables, moving them from one to the other requires an INSERT into the destination and a DELETE from the source table. There is the possibility that the DELETE happens and the INSERT does not (lag, error, whatever). Proper use of transactions should eliminate this, as well as referential integrity, but whatever.
The second example, all items are in one table. Just a column for the location. So that moving things from Inventory/Bank to cache on TR becomes: UPDATE PlayerGear SET LocationID = 3 WHERE CharacterID = X and LocationID in (1,2).
Now nothing can get lost. If the statement fails the items are still in existence. They are just not in the cache. Much easier to resolve.
And, yes, I know this is overly simplistic and I have no knowledge of their database design, technology or systems. I'm just saying there are ways to skin this cat without risking losing data.
no Ash, beside the fact that tye have stated numerous time that the TR cache is not tied to an account, the way the game works makes it impossible to have either option :
- The TR Cache does not exist until you TR a character. ( corrolary : it's not in the initial character structure )
- When a TR Cache is 'lost' there is no way to get it back. ( corrolary : it is not tied to the account and not directly tied to the character )
The only way to do it the way the limitations make it look is by creating it at character 'destruction', while giving it a character ID, and adding that character ID to the character structure once it's recreated.
The character ID informs the game that there's a TR cache ( if no character ID, then no TR cache to open ), and the Character ID is also the Index that allows for the item retrieval.
It's clunky as hell, but it fits with the fact that TR was a late game addition to keep people busy, done with a limited ressource pool and a limited amount of money.
They couldn't afford to rebuild the whole datamodel just for it.
I do agree that either of the models you presented would have been better, but there's still that small issue that the game delete the character from the server before recreating it... and doing it your way would open a can of worm that
Turbine SSG probably doesn't want opened.
( how do you store the items while the character is deleted from the server ? the only location where it's can be stored is in the client memory... do you ( as a player ) trust your client enough with your loot while your character is recreated ?... do you as SSG trust your client enough to be tamper proof while the character is recreated ? )