Question about storing custom content for every user in ASP.NET website

[Arcadio]

I need to present custom content to each registered visitor to a website. Each visitor will see custom content, not visible to other users. What's the best way to store such content and link it to every user? I was thinking of creating a database table for every registered user, and storing the custom content in such database, but that seems overkill. Maybe an XML file would be better?

What do you suggest?

 

[Train]

Why a table for every user? Why not just one table for all?

How often will the content change? XML should really only be used if you plan on it being very static.

 

[Arcadio]

Content will be added at any time for each user.

I just checked the ASP.NET documentation and I just figured out I can use the Profile API and create a custom class with the content. The class would be stored in the Profile.

 

[Train]

Content will be added at any time for each user.

I just checked the ASP.NET documentation and I just figured out I can use the Profile API and create a custom class with the content. The class would be stored in the Profile.

Ya but how long does the profile persist? And where is it stored?

Likely better off just making a table with a row for each user.

 

[Arcadio]

Ya but how long does the profile persist? And where is it stored?

Likely better off just making a table with a row for each user.

The Profile is permanent. It is stored in a database managed by the ASP.NET framework.

 

[Stuxnet]

Ya but how long does the profile persist? And where is it stored?

Likely better off just making a table with a row for each user.

He's almost certainly referring to the Membership API that's been included since ASP.Net 2.0.

OP: Even though Train's "concerns" are somewhat misguided, I would still advise not using the Membership API to facilitate this. You don't want gobs and gobs of content/HTML so tightly coupled with your user data and, worse, residing in the aspnetdb database (or whatever you chose to call it). You want this in your primary app database in a purpose-built table.

Think about it: what you're after is quite similar to how forums and wikis work, so look at their approaches. Some are file driven, but most are db driven. If the amount of content per user is relatively small AND you have a manageable number of users AND the content isn't being updated constantly, a file driven approach is absolutely fine. If one of those three criteria doesn't hold, I would strongly recommend a dedicated table(s) in your app's database.

 

[Train]

He's almost certainly referring to the Membership API that's been included since ASP.Net 2.0.

OP: Even though Train's "concerns" are somewhat misguided, I would still advise not using the Membership API to facilitate this. You don't want gobs and gobs of content/HTML so tightly coupled with your user data and, worse, residing in the aspnetdb database (or whatever you chose to call it). You want this in your primary app database in a purpose-built table.

Think about it: what you're after is quite similar to how forums and wikis work, so look at their approaches. Some are file driven, but most are db driven. If the amount of content per user is relatively small AND you have a manageable number of users AND the content isn't being updated constantly, a file driven approach is absolutely fine. If one of those three criteria doesn't hold, I would strongly recommend a dedicated table(s) in your app's database.

I don't see how I was misguided, especially since you recommended the same thing I did.

 

[AyashiKaibutsu]

Yea, I suggest a database and make it based on rows for users and not tables. It's easy to programmatically make/reference rows. Tables are more messy to reference when they're variable.

 

[Arcadio]

Yea, I suggest a database and make it based on rows for users and not tables. It's easy to programmatically make/reference rows. Tables are more messy to reference when they're variable.

Ok, I'll use one table with a row for every user. Now to deal with the fact that the columns of the table are dynamic. The number of columns will grow with time...

 

[Stuxnet]

Ok, I'll use one table with a row for every user. Now to deal with the fact that the columns of the table are dynamic. The number of columns will grow with time...

NO.

Say it again with me... "NO."

I've never encountered a situation that required a dynamic table structure, and I've worked in some fucked environments on some fucked up projects.

NO. 🙂

My guess is you're thinking that the columns need to grow to account for each type/category of content. Crazy idea, but why not make that a field in the table? Each user would have multiple rows in the table, and each row would be a specific category of content. Link the category value to a Categories table that gives meaningful short/long descriptions for each category, a bit indicating whether or not a given category must be unique per user, etc.

I don't see how I was misguided, especially since you recommended the same thing I did.

I apologize; that sounded much more condescending than I intended it to.

 

[clamum]

I've done something similar in ASP.NET before. I used a database table with a row for each user.

What I stored in a column was a semi-colon (I think, could be any character of your choosing) delimited string of settings. After the user logged in, I grabbed the proper row from the table, parsed the settings string, and set the user's custom settings.

 

[Leros]

For the stuff that is the same for every user, have a single fixed table (with one row per user) like so:

UserID | field_1 | field_2 | etc...

Then for the things that will be different for various users, have a properties table like so (with 0 or more rows per user):

UserID | property_name | property_value

 

[Saint Nick]

You should just store it all in a pipe delimited plain text file. That'll be easy and convenient to manage!

 

[Krioni]

THIS!

NO.

Say it again with me... "NO."

I've never encountered a situation that required a dynamic table structure, and I've worked in some fucked environments on some fucked up projects.

NO. 🙂

My guess is you're thinking that the columns need to grow to account for each type/category of content. Crazy idea, but why not make that a field in the table? Each user would have multiple rows in the table, and each row would be a specific category of content. Link the category value to a Categories table that gives meaningful short/long descriptions for each category, a bit indicating whether or not a given category must be unique per user, etc.



I apologize; that sounded much more condescending than I intended it to.

 

[Krioni]

This sounds like a classic Many-to-Many relationship.

As noted above, create your User table, a CategoryType table, a UserCategory table that maps users to categories and has their custom content... Something like that.

User:
-UserId (PK)
-OtherCrap

Category:
-CategoryId (PK)
-Description
-OtherCrap

UserCategory:
-UserId (FK)
-CategoryId (FK)
-OtherCrap
-MoreOtherCrap?

Hope this makes sense... especially since I've had a few 😉

 

[AyashiKaibutsu]

You should just store it all in a pipe delimited plain text file. That'll be easy and convenient to manage!

I think he should make a 32 bit binary key with the first 8 digits marking the user and the rest flagging which content (ordered by creation date) he gets.