3 ms·

But if there is a straightforward solution that allows you to not make these concessions and it can do so with great performance, I'm not sure how you can conti

by sbov 16y ago

But if there is a straightforward solution that allows you to not make these concessions and it can do so with great performance, I'm not sure how you can continue to claim that relational databases are the right tool for this job. Sure, it can do it, but it seems like something else does it better.

ameasure 16y ago
You're right, I don't have much of an argument for relational databases here. I am concerned about the complexity of this approach though and I don't think the concessions we're doing away with are that terrible. How meaningful is it to be rank 5623 vs. rank 5249, or even rank 2519? I don't think people can make much sense of ranks beyond 100, but maybe I'm wrong. I would rather break rankings into smaller groups. Which is more interesting, being ranked 23,528 worldwide, or being the town champion? I think the latter is much more meaningful to a person.
- latch 16y ago
  limiting ranks (to 5000 for most games and 1000 for a few particular ones) is the concession we ended up doing in v1. When we introduced the change, no one complained (or has since) - our developers have been great. As for complexity. The complexity of learning is a noop as far as I'm concerned. Duplicate data? Not concerned. Managing 2 stores...slightly concerning. Agreed. Maintenance? The entire change is largely encapsulated in a new ~30 line Rank class. Sure, I'd rather not have that extra code. I hadn't considered rank-groups (thanks for the idea though!). I'll definitely give that more thought. Nonetheless, I think I rather have the raw data available and accessible (in addition to any additional abstraction). I don't like making decision for the developers. Maybe 100 ranks isn't enough for them (I've seen them do some pretty creative stuff with the bit of data we're collecting already).

3 ms·

But if there is a straightforward solution that allows you to not make these concessions and it can do so with great performance, I'm not sure how you can conti

by sbov 16y ago

ameasure 16y ago
You're right, I don't have much of an argument for relational databases here. I am concerned about the complexity of this approach though and I don't think the concessions we're doing away with are that terrible. How meaningful is it to be rank 5623 vs. rank 5249, or even rank 2519? I don't think people can make much sense of ranks beyond 100, but maybe I'm wrong. I would rather break rankings into smaller groups. Which is more interesting, being ranked 23,528 worldwide, or being the town champion? I think the latter is much more meaningful to a person.
- latch 16y ago
  limiting ranks (to 5000 for most games and 1000 for a few particular ones) is the concession we ended up doing in v1. When we introduced the change, no one complained (or has since) - our developers have been great. As for complexity. The complexity of learning is a noop as far as I'm concerned. Duplicate data? Not concerned. Managing 2 stores...slightly concerning. Agreed. Maintenance? The entire change is largely encapsulated in a new ~30 line Rank class. Sure, I'd rather not have that extra code. I hadn't considered rank-groups (thanks for the idea though!). I'll definitely give that more thought. Nonetheless, I think I rather have the raw data available and accessible (in addition to any additional abstraction). I don't like making decision for the developers. Maybe 100 ranks isn't enough for them (I've seen them do some pretty creative stuff with the bit of data we're collecting already).