Calculate 'receiving' as the result of last payday.

[zbynekwinkler]

In response to #1127. I've prepared some simplistic tests. Am I heading in the right direction?

[zbynekwinkler]

@whit537 I've had some more time to think about it. How much do we want to keep the data in the db normalized and calculate most of things at display time? I must say that I lean in the direction of doing the most work at write time and in the show time just display what is in the db. I have some experience with google appengine and it almost forces you to do it this way by the api design. It leads to fairly scalable applications (we could avoid problems like #1417). However, from looking at the code you are in the other team, right?

I'd be tempted to make the dollars giving/receiving a column in the participant table and update it either at payday or at tip changing time.

[mvdkleijn]

@zwn @whit537 If I may chime in here. I would respectfully suggest that you shouldn't be in either camp. Look at the data and look at how often it is pulled / requested.

If a user requests it only once, just calculate it at that time. If a user requests certain data often, store it and recalculate only if and when it changes. That will get you the most bang for your buck as it were. The likes of Google et all have so many users that is almost always cheaper to cache or store calculated values. I do still think that early optimization is a killer.

[mvdkleijn]

Note: in this case I'd store the (at payday) calculated result and update the stored result when people change how much they give (or take from a team). You can use payday to "recalibrate" as it were.

[chadwhitacre]

Closing per conversation at #1127 (comment). Conversation re: schema design copied over to "contrib doc for db" (#1272).

@zwn I think 5ddddf6 looks good. Want to open a new pull request for that commit?