herein lies data retreival requests necessary for USER X
Reflection: should this be STORED or derived? Purists would argue it is derivable so you should
work it out each time, but as this stat is displayed on every users feed every time they refresh,
there is a strong argument for storing this and updating it each "follow this prattler" action.
This is the same PERFORMANCE vs PURIST debate that is necessary for queries B, C & D.
What do you think?
Reflection: this UNION is necessary given the current structure because we want to MERGE userx's prattles
with those of their followers. The order imposed last does the whole most recent on top, ancient below thing.
It seems cumbersome and without testing I have no idea how much strain this process puts on the
underlying database. Another issue - for users with LOTS of followers, who say lots, the feed will be MILES long
- we need to investigate some "clever" way of LIMITing the number of prattles that are displayed
- the "LIMIT" function in MySQL might be a good place to start.
Another issue emerges (a social and ethical one)- displaying prattles is all very nice but how many do we display,
how far back in the prattle history do we keep - some users prattle on endlessly and others prattle very little.
Is it fair to differentially chuck out prattles merely because they have lots to say? Is it fair to jettison prattles
after a DATE? Are there any legal requirements for actually keeping a perpetual record of all prattles,
given this is an open service, anyone can view it, anyone can say anything they like and there are laws
regarding defamation, libel and fraud?
What do you think?
Reflection: Arranging these icons in bunches of 5/6 per row represents an interesting programming challenge,
akin to pagination and almost certainly requiring an iteration of some sort with a conditional issuing of
either <BR> or a </TR> to terminate the row and establish another. Is there a smart way of doing this?
no, silly, this will not work - why?
