Best practice for managing anonymous users' data

Question

I'm looking for any hints on recommended, or simply tried and tested, ways of associating data with an anonymous user in a web application. I want the data to be available to users across multiple sessions, so therefore store it in the database.

Obviously I will need some kind of cookie to identify that user, what I'm particularly interested in is how to manage the link between this anonymous identifier and the actual data. So far I am exploring two options:

1. Creating a persisted anonymous user with each unique visitor. This way my data doesn't need to care whether it belongs to an anonymous user or registered one, it just belongs to a user.
2. Have some kind of wrapper/manager for the data that uses its own unique cookie value to associate with the data.

The main issue with #1 is the number of users getting created. Running a script every 24 hours to clean the table out would be easy, but I could still be creating thousands (I hope!) of rows per day, keeping them for say 14 days would result in a lot. With #2 I have to build an anonymous/cookie-based infastructure thats specific to the data, but what happens when I have other sets of data that need the same functionality.

Does anyone have any best-practice advice on how this might be done? I'm working in ASP.NET MVC with NHibernate, but concepts and ideas fom any platform would be helpful.

Answer 1

I would probably go for case 1. A few thousand rows a days is a small amount of data, not something you should worry about. This sounds like a one of those cases where you just get it working and worry about performance later (probably never).

You could probably never clear it out and still never run into problems.

Answer 2

It doesn't make sense to persist an anonymous user for two reasons:

1. Here today gone tomorrow. You'll be left with lots of orphaned rows which you'll have to rake every now and then
2. Persisting to a DB would imply that you can do a lot of customizations for these users which is a bad idea because it's all hanging by a cookie

I would suggest either using the cookie not only to track them, but also as a data store. Or option two where you handle them separately from registered users.