开发者

Asp.net Membership ProviderSql

开发者 https://www.devze.com 2022-12-20 12:46 出处:网络
I\'m looking into Asp.net Membership Providership Sql to determine if it fits my needs and have a few basic questions.

I'm looking into Asp.net Membership Providership Sql to determine if it fits my needs and have a few basic questions.

It seems to create a lot of tables, many of them I don't think I need. I only need one application and no role management. Can I remove the unused tables or should I just leave them alone?

I need another table where I can associate records with the users created with the Sql membership provider. Is it safe to use the "Membership.GetUser.ProviderUserKey.ToString()" as the primary key for this user. I guess so, but it feels a bit like I'm depending on something that's out of my control since it's Asp.Net that manage it.

Also I'm going to access the database directly, without logging in with a user 开发者_运维问答to get statistics. Is it safe to make Sql queries against the database using the aspnet_Users.UserId (table.field). I guess what I'm afraid of is that suddenly after an framework update, Asp.Net changes the table layout or something.


Obviously, you can do whatever you want to it once you've generated the tables, but I think you should consider the ramifications of that. The Membership Provider framework works very well and is widely implemented. If you use their implementation, just use it and use the pieces you want and leave the rest alone.

They will be very careful when/if they make changes to it to either tell us of the breaking changes or not make any breaking changes.

The framework allows for you to override many of the provided methods, or you can simply write you own custom provider and base it heavily on the out of the box implementation.


ProviderUserKey is meant to store anything you would need to reference, so you can store a key to a record in your own database to store additional user information. I think it's OK to delete unrelated tables, as long as the features you use don't touch it.

I know it touches aspnet_applications, aspnet_users...

As a last resort, you can always create your own custom membership provider by creating a class that inherits from MembershipProvider.

0

精彩评论

暂无评论...
验证码 换一张
取 消