I need a substantially bigger member profile than that shown in the Beer House Starter Kit. I want to store member's audio and video files as well as lots of searchable characteristics.

It seems to me I have some choices:

• Put some links to files in the standard profile stored in the aspnet.profile table in ASPNETDB
• Write a completely new user profile using standard PROCs and tables the way I did in ASP.NET 1.1
• Use Hao Kung's method to convert the default long string format into separate tables
• Have a hybrid user profile architecture with basic info in the aspnet.profile table and the rest of the information in separate tables linked to the aspnet.users table by UserId

I'm leaning towards the last solution. I would like to put pictures and media files in SQL2005 directly as blobs. Formerly I always stored file links but perhaps SQL2005 is mature enough now.

It seems to me that it will be harder and slower to search long strings than separate indexed tables.

Any advice?

__________________
http://weboperahouse.com
http://www.boyleed.com

I was indeed thinking something similar as I need to get other information also, so I am going to have a play with it over the weekend, as it seems my work week is full already :S

--

404 real life user not found

SQL 2000 wasn't bad at doing this, but both flavors of SQL should have separate DBF file groupd for this kind of thing, and that wouldn't work with cheap shared hosting sites.

I personally never store large blobs in DBs, but it's easier to keep the data together if you do.

I also see Profile storage as being most appropriate for non-essential data.

Eric

Eric,

Thanks for the advice. I've been holding off until I got some feedback on the best way to continue. I will [u]not</u> store blobs in SQL Server 2005. I would like to, but I will wait until I read uncontroverted testimony from someone who has had great success with this particular approach.

What is a "cheap shared hosting site"? I use, as I believe you do also, WebHost4Life. Do you mean other vendors? Or do you mean shared versus a dedicated server?

I don't intend to have more than one database - just another table in my one database.

I am a bit troubled by the architechture of the new ASP.NET 2.0 Profiling system. It seems to violate the spirit of relational database. When I have a perfectly good real dbms that optimizes execution plans for queries, why would I want the system to do string searches?

The Profile system appears to me to be like the new Declarative database features. True they make up the CRUD syntax and populate a GridView control with drag and drop, but it's all in the code behind presentation tier. Real apps will still need a DAL and PROCs.

I think a real app needs a profile based on a DAL and PROCs too. I'm going to restrict the Profile in aspnet_profile to just a few fields that are populated by the built in registration system. I will store details is another conventional table.

Any hosting company that requires you to share a common installation of SQL Server with hundreds of other users meets my description of cheap shared hosting. I am not against this, but you can't optimize the physical storage organization because you don't own the overall server installation.

I guess you thought the Profiling system should be more than it is. It was only intended to be a persistant version of session state. It's supposed to hold preferences and defaults for users, and nothing more. One of my friends likes to say that it shouldn't hurt your company's bottom line if you suddenly lost 100% of your profile data.

Eric

On my vendor, my premium shared hosting account costs me $20/mo. The cheapest dedicated plan costs $300/mo. OK, I'm cheap. If my site generates enough traffic to justify an optimized host, I'll be happy to upgrade.

Thanks for the perspective on the Profiling system. I didn't really expect anything of the Profiling system. I just wanted some advice about how best to exploit its strenths.