|
Subject:
|
Membership modifications...should I?
|
|
Posted By:
|
Tremmorkeep
|
Post Date:
|
6/26/2006 5:46:09 PM
|
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.
|
|
Reply By:
|
englere
|
Reply Date:
|
6/26/2006 7:59:45 PM
|
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
|
|
Reply By:
|
Tremmorkeep
|
Reply Date:
|
7/20/2006 4:42:28 PM
|
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?
|
|
Reply By:
|
englere
|
Reply Date:
|
7/21/2006 10:20:01 PM
|
Column UserID in table Aspnet_Users is the unique key - it stores a GUID.
|
|
Reply By:
|
spardoe
|
Reply Date:
|
8/8/2006 7:37:35 AM
|
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
|
|
Reply By:
|
englere
|
Reply Date:
|
8/9/2006 9:31:47 PM
|
>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
|
|
Reply By:
|
spardoe
|
Reply Date:
|
8/11/2006 7:43:21 AM
|
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
|
|
Reply By:
|
andystephens
|
Reply Date:
|
8/29/2006 9:11:19 AM
|
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);
|
|
Reply By:
|
Imar
|
Reply Date:
|
8/29/2006 9:56:04 AM
|
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.
|
|
Reply By:
|
LAM
|
Reply Date:
|
9/21/2006 12:36:13 PM
|
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:
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.
|
|
Reply By:
|
englere
|
Reply Date:
|
9/22/2006 4:20:39 AM
|
You don't need to write your own provider if you're using SQL Server and you understand the way it uses the aspnet tables. Your task would be to ensure that you are backing up those tables and you need to consider those tables as being part of your essential database. Some people make the mistake of ignoring those aspnet tables and they put themselves at risk that way.
Every system developer needs to document the tables used by the system, along with a description. And the backup and recovery plan needs to include all those tables, which is mostly a concern if you don't perform backups by copying the entire DB verbatim. Lots of people perform delta backups of tables, especially for cases where the tables are huge and a full backup can't reasonably be done on a daily basis. But this is a big subject and I don't want to get into too deep in this forum.
There are many web pages that discuss writing your own providers if you're an advanced developer and you have a reason to do that. It's not easy and it's way to easy to do it wrong, so I don't suggest this for most people. If you get it wrong you are placing a lot of data in jeopardy.
Eric
|
