Efficient way of setting up read/unread system

[TheSmileyCoder]

Does anyone know a good resource explaining the most efficient way to setup a read/unread system?

I have a system with about 50 users, and I would like to setup a system where they can view what items are new or unread.

I imagine there a quite a few ways of doing this, and I think I could spend quite a bit of time on this, so I want to make sure I set it up the most efficiently from the start.

Such questions come to mind such as:
Is it best to keep track of the read posts or the unread posts?
I can see if you want to keep track of read posts, and have a table of such, you might end up with a rather large table. Imagine 1.000 users and 10.000 threads, that makes for 10.000.000 entries into the table. That starts to sound a little extreme to me. I know I will have less users, but I expect around the same number of entries. (50 users, 10.000 threads so 500.000 entries in table)

Therefore I was considering if it would be easier/more efficient to simply keep track of the unread posts.

Anyways, Im sure someone has thought alot more about this then I has, and I would appreciate any knowledge/links you guys can provide.

[NeoPa]

I know of no links, but I guess the first thing you need to determine is which of the two (read or unread) is likely to be the more populated. Clearly, all else being equal, you'd want to hold as little data as possible. This question isn't as obvious as it may seem though. You may have a scenario where not reading items is very rare, as there may be instructions from above that all need to be read. I don't know of course. Only you know those details.

The next issue I would consider would be whether an item could be considered to have been read (or at least there is no interest any more whether or not it actually has been) after a certain period of time has elapsed. I believe this is quite common in forum software such as drives Bytes.

You would also need to consider whether or not a new user being set up, would be required to reflect all historical items. Clearly the expiry of interest issue would become more important the more data was being stored and managed in the database.

[ADezii]

How about an Internal, strictly Access based System which can send Messages to other Users without using E-Mail in a Multi-User environment using a Table, Form, and the Timer() Event? Messages/Posts can be marked as Read, then dynamically removed at will. The System would involve a FE...BE setup as well as some mechanism for uniquely identifying Users via some form of Login.

P.S. - Sorry TheSmileyOne, accidentially replyed to NeoPa instead of you. Don't get offended NeoPa, it's not that I mind conversing with you! (LOL)

[NeoPa]

No worries my friend :) In fact it is a quote, rather than a reply (Forget the buttons. Their names can be misleading). Quotes are only ever required when specifically drawing attention to an individual post or part thereof. As it happens, the current style doesn't even display the quoted text anyway so is almost entirely pointless, though it does include a link to the referenced (whole) post, which can be of some use.

Unless a response specifically refers to a post which is not the latest one, or maybe refers to a specific part of the latest post, then it is not good web-etiquette to quote at all. I cannot count the number of times I read through the quote simply to find it was a simple copy of the post I'd already just read. IE. Someone just wasted my time. Essentially, only quote if that extra text helps a reader to comprehend the response better. Sometimes the context is important, but often it adds nothing.

[TheSmileyCoder]

I forgot to update this, and I've been meaning to do it for a while, but keep forgetting. No more postponing it.

In the end, I realised that while most people would be reading alot of items within a narrow area, there would also be alot of areas that would never be read. (Like I never read the php section of bytes, but probably read 50% or more of the access area posts.)

So I decided to go with keeping track of when a user opens an item (items are opening by clicking in a treeview, showing all/filtered results. So I recorded 3 things, the user, the Item id, and the time they clicked it.

The next time the treeview is updated, I would color the items according to whether or not the item had been modified after the recorded time of viewing. I join up the table of read items with the items presented in the treeview, before making the treeview, so I would have as few queries/joins as possible. In the end it worked really good and people like the feature alot.

Thanks for the input given.

[NeoPa]

It sounds like a pretty neat solution you have there Smiley :)

No worries about the delay BTW. When you're only looking at threads with changes, who notices if one lays dormant for a while.