Right. But they would have to maintain a data structure that stored all the userid's that have previously read the post. And then check that structure doing maybe a fast heap sort before deciding if an increment were justified.
I can see that with a site viewer counter, but maintaining a data structure for every ihub post might be a little unwieldy. You couldn't just do it just for a board, because if a user reads 10 posts, you want the board to register 10 reads.
Yikes, think about it. 60,000 ihub members! The data structure would have to potentially store 60K entries. And you need one for each ihub public message. Maybe 4 million times 60K. 240 Gigtimes say 5 bytes to store a user id. And you wouldn't use 5 bytes - there is no 5 byte variable type, you would use 8. 1.6 terrabyte structure. Hmmm, sounds unlikely. Maybe something clever could be done like just store the last userid that incremented the counter for that particular post and disallow increment on consecutive reads.
HEY BOB, what say you? Is this feasible?
News 
Market Data 
Discover 
