Inter-Level Experience Reset - A Possible Solution

[Anonicat]

The calculation is the part that takes a long time, and if they’re doing it for every data point, there’s bound to be repeat calculations in there. So instead, make a solution lookup table.

You calculate every possible value and what it maps to in advance and store them in a separate table. Going by this chart, the table would only need ~325M rows (not nothing, but also not unreasonable, especially if you partition it right), and would be fully static. This would mean that it could be indexed extremely easily, and the indices would have zero chance of going stale. Rather than calculating everything, you’re just joining another table, which is extremely simple in terms of design, implementation, operational complexity, and execution.

Doing a full table update over ~2B rows without any math would take maybe 15 minutes.

And perhaps they did consider it, but perhaps not. I just saw the operational complexity and know there’s an easier way to do it (because I’ve done it).

You're not suggesting making a table row for for literally every experience point are you?.... then trying to join it... with other tables are you....

[Jpec07]

You're not suggesting making a table row for for literally every experience point are you?.... then trying to join it... with other tables are you....

That’s precisely what I’m suggesting. A nonvolatile table with 325.8M rows, fully indexed and partitioned, will be incredibly performant for a join like this.

[Anonicat]

That’s precisely what I’m suggesting. A nonvolatile table with 325.8M rows, fully indexed and partitioned, will be incredibly performant for a join like this.

No read my other response. That's too much. Why join a table that big.... there is still a performance hit. Just cause the algorithm for joins is optimal doesn't mean it won't take some time.

See my other response.