Personalization Personified
- Storing the MyInformIT Data
- From Recordset to Browser
- Finally, the HTML
- Deleting Unwanted Entries
Man, oh man, I hate Mondays! It should be a mandatory practice that the Monday workday start no earlier than noon. For that matter, Fridays should end at noon too. I think that there would be a noticeable increase in productivity during the rest of the week that would offset any loss of time on the clock. Are you with me? What do you do on a Monday from the time that you arrive at work until lunchtime? I drink several cups of coffee and catch up with everyone else about how their weekends went. It isn't that I don't like chatting with my fellow code monkeys, but I could easily be spending that time sleeping. It would sure improve my mood, if nothing else.
Maybe I just take the developer stereotype—lack of sleep, too much caffeine, bizarre outbursts—a little too far. I suppose that I could try to get to sleep before 1:00 a.m. on Sunday night, but then I wouldn't be squeezing every last drop out of my weekend. If I had a buffer zone on Friday afternoon and Monday morning, maybe I wouldn't feel the need to wring every quality moment out of my free time late at night. A sleep schedule like mine only succeeds for so long, unless one is a vampire. Come to think of it, I am a little pale...
Anyway, there's an extra incentive to do nothing on Mondays here at InformIT. Akin to an enclave of the gods gathering in Asgard, Mondays herald the congregation of InformIT managers in a conference room known, inexplicably, as Le Cave. This portentous meeting is known as management council or just MC. It's basically a forum for the president of InformIT to publicly immolate his management staff for a healthy three or four hours. In the process, they also try to set priorities for the rest of us in Midgard that will determine our fates in the coming weeks.
For those unfortunate lesser godlings known as directors, this is a hectic and painful time. They have reports to present and explanations to put forth as to why InformIT's page views aren't what they should be. For us mere mortals, it's a time to sit and reflect. Any work we accomplish Monday will be for naught. Our priorities inevitably change as a result of MC, and anything we have toiled over that morning gets tossed in the circular file. I guess it's just the fate of lesser beings to puzzle at the capricious whims that drive our lives.
Storing the MyInformIT Data
It's also a good reason to give you, the users, something to feel better about. That brings us back to the MyInformIT page. When last we met, I discussed how the process of adding content to the MyInformIT storehouse works. This week, let's take a look at how the MyInformIT data is stored in the database, and how we bring you that which you see in your "My Saved Content" list. Figure 1 shows an example of my MyInformIT page.
){kind=link}
Figure 1 My oh MyInformIT.
With that in your mind's eye, let's look at a simplified database diagram of the user table structure that allows us to link your login with the content that you've saved. For clarity, Figure 2 pares it down to just the relevant tables and fields.
){kind=link}
Figure 2 Session/user/linked products table structure.
It doesn't get any simpler than this. The users table stores your unique email address and the username that you have selected. The primary key for this table is a uniqueidentifier, the user_id. On the right, we have the linked_products table. This associates your user_id with a product_id and element_id. If you'll recall, the product_id uniquely defines a book or article, and the element_id identifies a given page of an article. The user_id, here a foreign key, forms a primary key with link_id, another uniqueidentifier assigned to each link.
We figure out who you are by checking your session_id. Because we're running our site in a multi-server, load-balanced environment, we decided to eschew the built-in ASP Session object and write our own. Ours works essentially the same as Session, allowing the storage of select variables for a user session on the server. If your session hasn't timed out, and you're a registered user, we can tie your session_id to your user_id. If your session has timed out, you log back in, get a new session_id, and we can still grok your user_id.