0👍
It’s a bit more difficult to have points saved in the same table, but it’s totally worth it. You can do very simple ordering/filtering operations if you have computed points total on user model. And you can count totals only when something changes (not every time you want to show them). Just put some validation logic into post_save signals and make sure to cover this logic with tests and you’re good.
p.s. denormalization on wiki.
2👍
this is old, but I’m not sure exactly why you have 2 separate tables (Points Added & Action). It’s late, so maybe my mind isn’t ticking, but it seems like you just separated one table into 2 for some reason. It doesn’t seem like you get any benefit out of it. It’s not like there’s a 1 to many relationship in it right?
So first of all, I would combine those two tables. Secondly, you are probably better off storing points_total into a value in your site_user table. This is what I think Demitry is trying to allude to, but didn’t say explicitly. This way instead of doing this whole additional query (pulling everything a user has done in his history of the site is expensive) + looping action (going through it is even more expensive), you can just pull it as one field. It’s denormalizing the data for a greater good.
Just be sure to update the value everytime you add in something that has points. You can use django’s post_save signal to do that
- [Answered ]-Django Queryset most accurate search result
- [Answered ]-Model with instance won't save to DB but no error message in Django