Unregistered users in database

Question

I'm creating a discussion forum (of sorts) in ASP.NET MVC, and I have a requirement to allow posts by unregistered visitors. Visitors only need to specify an alias to post, and can optionally provide an e-mail address and a website url.

What's the best practice in handling posts by unregistered users in a database?

I'm a bit of a newbie in database design, but these options come to mind:

1. Insert new record in the Users table for each post by an unregistered visitor. (Would make queries easier when records in Posts and Users tables will have a 1-to-1 relationship, but bloats the Users table)
2. Create new table for unregistered users, and create new entries for new alias-email-url combinations, reuse existing ones. (In such scenario, would I have two foreign keys in the Posts table for RegisteredUserId and UnregisteredUserId?)
3. Add UnregisteredAlias, UnregisteredEmail and UnregisteredUrl fields directly to the Posts table. (Awfully denormalized, but then again this seems like a clean solution to me. Would I then make the UserId field of the Posts table nullable, and set it to null for these posts?).
4. The obvious solution I haven't yet thought of?

Would any of these solutions cause problems with mapping LINQ To SQL?

Edit:

To clarify, I do need to store an alias (a name), and an optional email address and url for each post made by an unregistered visitor. This information is displayed with the post, so visitor != anonymous in this case.

Answer 1

The problem with alias is that without a form of user registration another user would be able to post with the same alias, and thus "taking over" his identity.

I think I would either make UserId optional in the Users table or a 1-1 mapping between users and posts and add a second table to hold the Email/Url/(Alias) for unregistered users.

Answer 2

Personally, I'd go for option 1, "Insert new record in the Users table for each post by an unregistered visitor."

Why? Well, a User is a User, right? The fact that they have registered on your site becomes a property of that user (i.e. a field within your Users table).

Doing it this way greatly simplifies your database design, allowing you to retain a sane amount of normalization and avoids you having to introduce de-normalized duplication into the design (i.e. A having an "unregistered users" table along with a "registered users" table I would consider to be duplication and overcomplicates the design and relationships of your database entities).

Moreover, Option 1 makes your code much simpler for when an unregistered user wishes to become a registered user. This becomes merely the setting of a few fields on the user record. Assuming your database relationship will have a UserID field (as a foreign key) on your "Posts" table relating to the UserID primary key on your Users table (or some such design) you need do nothing when an unregistered user becomes a registered user, whereas with your other options, you would need to either remove (blank out) fields from potentially numerous previous posts (option 3), or delete and re-create records in multiple tables (option 2).

(assuming, of course, that you don't wish to retain the fact the a user was unregistered when some previous post was made!)

Answer 3

Have a user named "Unregistered" (or something like that) in your users table and have that account own anonymous posts.

In response to CraigRP's comment below :

I would either ask for a name in a textbox and attach it to the bottom of the post like a signature. Or wouldn't care about differentiating at all. After all, anonymous is anonymous.

Answer 4

I think this is the same as your option3:

The posts table would consist of

UserID (nullable) UnregisteredUserID (nullable)

and then the rest of your fields.

One of UserID or Unregistered ID would be populated.

Unless you have a "register new user" page there is no point in adding the user to the users table at all.

Answer 5

I would go with the out of the box Membershipsystem of ASP.NET. You have the option to allow anonymous users there. Once they create a login, their account properties are migrated.

Unregistered users would need a property "UserName". This would only be used for displaying the Username. They would be identified by their anonymous User ID.