Wrox Programmer Forums
|
BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0
This is the forum to discuss the Wrox book ASP.NET 2.0 Website Programming: Problem - Design - Solution by Marco Bellinaso; ISBN: 9780764584640
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old June 26th, 2006, 05:46 PM
Authorized User
 
Join Date: Jul 2003
Posts: 31
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via AIM to Tremmorkeep Send a message via MSN to Tremmorkeep Send a message via Yahoo to Tremmorkeep
Default Membership modifications...should I?

I have other information that I need to store with each profile, such as height, weight, etc for our business needs. Is it a better practice to modify the aspnet tables/procedures or to create a separate table, creating a one-to-one relationship (not very normalized). I'm new to asp.net and I'm just wanting some feedback.
 
Old June 26th, 2006, 07:59 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 917
Thanks: 0
Thanked 0 Times in 0 Posts
Default

My personal viewpoint is that you should never store important info in the ASP.NET tables, and you shouldn't even utilize them as a key. It's safest to assume that these tables might get wiped out at any time. However, you can use fields from a user's profile to get information that should go in another table, as long as you don't trust that the profile data will always be there.
  I think of it almost as a persistant cookie. It will normally be there, and may be there 99% of the time. But it's that 1% that can cause a lot of trouble.

Eric
 
Old July 20th, 2006, 04:42 PM
Authorized User
 
Join Date: Jul 2003
Posts: 31
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via AIM to Tremmorkeep Send a message via MSN to Tremmorkeep Send a message via Yahoo to Tremmorkeep
Default

Thats all well and good, but which table (aspnet_membership, *_profile, *.users) has the 'primary key' that I can use to relate this data to my 'PersonalInfo' table? I love the way membership is dealt with in asp.net 2.0, its fantastic... but I have a definite need to create a one-to-many relationship from the correct aspnet table to my own table and I'm trying to figure out which table (aspnet) drives it, and how to get to the primary key of that row. I'm not running any other applications so i'm not worried about that aspect of it. for simplicities sake, in classic asp I'd have 2 tables; users and items with a 1-to-many from users to items (items having a foreign key called (fk_Userid) How the crap do you do that with these aspnet tables?
 
Old July 21st, 2006, 10:20 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 917
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Column UserID in table Aspnet_Users is the unique key - it stores a GUID.

 
Old August 8th, 2006, 07:37 AM
Authorized User
 
Join Date: May 2006
Posts: 19
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Eric,
I'm concerned by what you said above. Why can't you trust the profile data will always be there? Could you elaborate a bit.

I'm also trying to set up a second table linking to the UserId in Aspnet_Users.
What would be the best way to delete related entries from this table when a user is deleted? Is it possible to use cascading delete?
Also, wouldn't it be better to UserName instead of UserId?

Cheers,
Simon


 
Old August 9th, 2006, 09:31 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 917
Thanks: 0
Thanked 0 Times in 0 Posts
Default

>Why can't you trust the profile data will always be there? Could you elaborate a bit.

Since I have little or no control over the built-in provider, and these tables may not be backed up by some backup procedures (I'm not even sure if my web hosting company backs them up), I prefer to treat them as reliable over the short term.

Some people do trust these tables over the long term, and I have no evidence that indicates there's any problem over the long term.

Microsoft has released some of their provider code and that makes me feel a little better, but it's not all public.

At work I've implemented my own provider, which uses my own table structures, and I do trust that method. The need for this was driven mostly by our requirement to use Oracle, and also to avoid the use of blob fields which are difficult to query against and to import/export.

I don't want to leave you with the impression that I dislike Microsoft's solution. For me it comes down to an architecture issue of exactly where the boundaries are defined. I'm a bit of a control freak and I tend to put "foreign" table structures ouside my own system boundaries. If I link my tables to "foreign" tables I'll do so in a de-normalized manner that has me storing copies of essential fields in my own tables. This allows me to re-construct the essential columns in foreign tables using data from my own core tables only, in case that need should arise.

Of course you can set up a cascading delete between your tables and theirs, assuming you will take control of deployment and not rely only on the aspnet_regsql utility to set up the tables. But this will tightly couple "your table" to "their table" so you'll need to pay attention to backup and recovery procedures. This is fine if you don't see any cause for concern there - this isn't a question of right and wrong, it's more about styles and whatever best practices you prefer.

Marco is using the aspnet tables as core to his design, and this was done to speed development and to demonstrate how to leverage the new providers in ASP.NET 2.0. It's not "wrong" to do it that way as long as you feel comfortable with the trade-offs and boundaries (your system boundary has to extend to cover those tables).

The issue of username vs userid should be based on your design needs. Sometimes usernames can change (most often related to a marriage or divorce), and you can keep the userid the same if your design keys off that instead of username. Sometimes users want to change their username to make it more consistant with other sites they use, also, or they may want to change to a username that camoflages their real identity (to give them more privacy in forums).

Eric

 
Old August 11th, 2006, 07:43 AM
Authorized User
 
Join Date: May 2006
Posts: 19
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thank you this is very helpful. You have raised a lot of issues that I hadn't actually thought of. I am hosting my website on my own server so I have complete access/control over things such as backup (although I haven't set that up yet) but I will probably migrate at a later stage to a hosting company so I need to take this into account.
I also hadn't thought about users maybe wanting to change their username (or email) so I will be using UserId as the key for the tables.
Thanks once again,
Simon

 
Old August 29th, 2006, 09:11 AM
Registered User
 
Join Date: Aug 2006
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi, so far I've been using the default membership provider (the SQL Express db in the app_data folder), but it would be nice to merge all this into my application's database due to a number of UserId foreign keys that are present in my own tables. This merging can be done using the aspnet_regsql tool, but does anyone have any experience of whether ISPs are willing to run this tool on your behalf?

BTW, it took me days to find out but if it helps anyone else: I had been wondering how to access the UserId of the current user from within my code. I eventually discovered that the MembershipUser class has a "ProviderUserKey" property (which may not be the most obvious name), which contains the value from the UserId column (it needs casting to a GUID). One way to get an instance of the MembershipUser class is to call Membership.GetUser(User.Identity.Name);


 
Old August 29th, 2006, 09:56 AM
Imar's Avatar
Wrox Author
 
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
Default

Quote:
quote:I eventually discovered that the MembershipUser class has a "ProviderUserKey" property (which may not be the most obvious name)
In a way it *is* the most obvious name. Microsoft recommends not to rely on this key as the primary key of the user. They may change the implementation to, say an Int in future versions without telling you. Instead, they advise you to use a combination of the Application and UserName.

So, the ProviderUserKey is really what it sounds like. The User's key internally for the provider. Use at your own risk....

Cheers,

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
Want to be my colleague? Then check out this post.
 
Old September 21st, 2006, 12:36 PM
LAM LAM is offline
Registered User
 
Join Date: Sep 2006
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi englere,

I really liked your viewpoint. Now, when you say, write your own provider, you mean to write all the code that interacts directly to the db? How would you go about doing it? can you point to an article online?

Just when I thought that we could save lots of time with the new user/membership/profile system included in ASP.Net 2.0 i realize that we still need to do most of the providers!

Regards,


Quote:
quote:Originally posted by englere
 >Why can't you trust the profile data will always be there? Could you elaborate a bit.

Since I have little or no control over the built-in provider, and these tables may not be backed up by some backup procedures (I'm not even sure if my web hosting company backs them up), I prefer to treat them as reliable over the short term.

Some people do trust these tables over the long term, and I have no evidence that indicates there's any problem over the long term.

Microsoft has released some of their provider code and that makes me feel a little better, but it's not all public.

At work I've implemented my own provider, which uses my own table structures, and I do trust that method. The need for this was driven mostly by our requirement to use Oracle, and also to avoid the use of blob fields which are difficult to query against and to import/export.

I don't want to leave you with the impression that I dislike Microsoft's solution. For me it comes down to an architecture issue of exactly where the boundaries are defined. I'm a bit of a control freak and I tend to put "foreign" table structures ouside my own system boundaries. If I link my tables to "foreign" tables I'll do so in a de-normalized manner that has me storing copies of essential fields in my own tables. This allows me to re-construct the essential columns in foreign tables using data from my own core tables only, in case that need should arise.

Of course you can set up a cascading delete between your tables and theirs, assuming you will take control of deployment and not rely only on the aspnet_regsql utility to set up the tables. But this will tightly couple "your table" to "their table" so you'll need to pay attention to backup and recovery procedures. This is fine if you don't see any cause for concern there - this isn't a question of right and wrong, it's more about styles and whatever best practices you prefer.

Marco is using the aspnet tables as core to his design, and this was done to speed development and to demonstrate how to leverage the new providers in ASP.NET 2.0. It's not "wrong" to do it that way as long as you feel comfortable with the trade-offs and boundaries (your system boundary has to extend to cover those tables).

The issue of username vs userid should be based on your design needs. Sometimes usernames can change (most often related to a marriage or divorce), and you can keep the userid the same if your design keys off that instead of username. Sometimes users want to change their username to make it more consistant with other sites they use, also, or they may want to change to a username that camoflages their real identity (to give them more privacy in forums).

Eric

LAM.





Similar Threads
Thread Thread Starter Forum Replies Last Post
Ch.7 - Autosuggest example - some modifications ice84 BOOK: Professional Ajax ISBN: 978-0-471-77778-6 10 September 17th, 2007 05:37 AM
"/Modifications" maxshreck BOOK: ASP.NET 2.0 Instant Results ISBN: 978-0-471-74951-6 3 October 10th, 2006 01:13 AM
Custom modifications to ThePhile meierk BOOK: ASP.NET Website Programming Problem-Design-Solution 0 October 1st, 2003 02:12 PM
how can i see the modifications in a form fields thomaz C# 1 September 7th, 2003 04:27 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.