SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    SitePoint Guru pinch's Avatar
    Join Date
    Mar 2005
    Posts
    688
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Managing Complex Anonymous User Data

    I'm developing a web application that allows users to create fantasy football cheat sheets. Registered users can start out with a sheet based on a multitude of configuration parameters they can specify (which position to base the sheet on, which stats to include in the sheet, how to initially sort the players in the sheet) and after this initial configuration stage they basically re-order the players . These registered users also have the option to save as many sheets as they like and, as I mentioned, configure the sheets to their liking.

    Now, I want to be able to allow anonymous users to create sheets as well, but they won't have the luxury of saving the sheet or configuring the many aspects of the sheet (they'll basically be able to choose a sheet based on a single position, QB for instance, reorder and print it).

    I'm wondering what would be the best way to approach the storage of the sheets that are modified by anonymous users. Should I use same database tables to keep track of anonymous sheets as I do for the sheets saved by registered users, using a special key to indicate that they are sheets owned by anonymous users? Then when an anonymous user's session expires I have to find his sheet and delete it.

    Would it make more sense to keep these temporary sheets in some data structure in memory so it would be easier to purge them if the user's session expires? This would ensure that I only keep data for registered users in the database.

    I definitely need to have the functionality to save an anonymous users' sheet if they decide to register after figuring out that they cannot save the sheet without registering.

    Any advice would be appreciated, thanks.

  2. #2
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,649
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    I would model the sheets separately from the users, then let users be linked to sheets. This would let you handle anonymous sheets, as well as multiple sheets per user.

    Side note: isn't it a bit late to start ginning up a fantasy football app?

  3. #3
    SitePoint Guru pinch's Avatar
    Join Date
    Mar 2005
    Posts
    688
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99 View Post
    I would model the sheets separately from the users, then let users be linked to sheets. This would let you handle anonymous sheets, as well as multiple sheets per user.

    Side note: isn't it a bit late to start ginning up a fantasy football app?
    I'm not sure about your first statement. My schema currently allows users to save multiple sheets, and currently the application functions well for registered users. Are you saying that I should use my existing database, and instead of keying off of registered users I should just key off of some string value the represents the anonymous user, storing them in the same table? Then if the anonymous user's session expires I can just delete their sheet?

    I regards to your second question, yes its a bit late ginning up a fantasy football app. I came up with the idea for this application about a month ago and have been working hard on it, but it appears I may have bitten off a bit much for my first, solely-developed ASP.net application. However, I'm hoping that the framework I'm putting in place will allow me to tailor the application to any fantasy sport and have a solid application at the ready for next season, if copycat sites don't start popping up. I'm sick that I missed the deadline for this year though.

  4. #4
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,649
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    I am guessing right now you have a table called "Sheets" which has a primary key and a foreign key to the users table, correct? What you need to do here is break to take the foreign key out of that table and make a join table to join sheets to users. Then you could also create a table to, say, link sheets to session IDs.

    Good luck with the site, sounds neat. Funny how these "little" apps always take 10x longer than one would think.

  5. #5
    SitePoint Guru pinch's Avatar
    Join Date
    Mar 2005
    Posts
    688
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99 View Post
    I am guessing right now you have a table called "Sheets" which has a primary key and a foreign key to the users table, correct? What you need to do here is break to take the foreign key out of that table and make a join table to join sheets to users. Then you could also create a table to, say, link sheets to session IDs.

    Good luck with the site, sounds neat. Funny how these "little" apps always take 10x longer than one would think.
    Ok I think I'm following you now. When accessing sheets for registered users I would just issue a JOIN between the Sheets table and my UsertoSheet lookup table whereas when accessing sheets for anonymous users I would just issue a JOIN between the Sheets table and my AnonyUsertoSheet lookup table. If a user decides to register I'd just remove his entry from the AnonyUsertoSheet lookup table and move it to the UsertoSheet lookup table.

  6. #6
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,649
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Bingo. Though you might want to ponder cleanup of Anonymous sheets as well.

  7. #7
    SitePoint Guru pinch's Avatar
    Join Date
    Mar 2005
    Posts
    688
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Awesome, thanks for the input.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •