I would really appreciate som guidance and debate about what is Best practice on implementing an external membership database or not.
I'm about to extend Umbraco to handle a memberdatabase on about 5.000 members and scaleable up to 10.000+ The members will have about 8-10 extra properties than the normal (Username, LoginId, E-mail, password).
The members will be administrated on a protected location on the site and the data should be retrieved here from the database. So any hints on minimicing load times would be preferable.
I only have experience with handling the members in the Umbraco database, but my experince tells me that this is very heavy to work with if the members is 1.000+, so my question is basically - Do I win anything if I put the data in another database.
Can you please provide the link where you read about som guidance and debate about what is Best practice on implementing an external membership database or not.
Umbraco implements the ASP.NET Membership API's, you should use that.
Whether or not you completely tie it into Umbraco for member management really comes down to the needs of your site administrators, but there's nothing to stop you from using the SqlMembershipProvider or anything else. Just tweak your web.config :)
One thing is to use the Umbraco tables for members/users - another thing is how to store member properties/profiles.
So far I have come to the conclusion NOT to use Umbraco membertype to define the extra properties for members. The properties can only be accessed/modified (in an easy way) using the API.
I think I will implement a custom Profile provider for my member details. Custom here means NOT the default profile provider that is serializing data into one string in the ASPNET database. Instead I want a table provider like this: http://www.asp.net/downloads/sandbox/table-profile-provider-samples/
So far I dont know if I will store my users in the Members section?
Pro: - Easy overview out-of-the-box
Cons: - Members will be split from their custom properties
My concerns with using the standard Umbraco membership provider is speed. I know for a fact that extracting member data and properties in eg. listviews can be very slow if I exeed 1000 members. So my question is basically can I get better results if I use a seperat database to handle the members and use a SqlMembershipProvider ? A demo of setting this up would be preferable. I know how to work thru the API allready.
Can I maintain the members inside Umbraco and make properties or do I loose this functionality.
I posted an article on the instructions for configuring the SqlMembershipProvider here: Configuring SqlMembershipProvider in Umbraco 7.0.3. The main challenge is creating the controls in Umbraco for managing the roles and membership since those features are disabled once you roll over to the new provider. You will want to create custom controls for that. Sounds like a good use of AngularJS.
Best practice on MembershipProvider
Hi All.
I would really appreciate som guidance and debate about what is Best practice on implementing an external membership database or not.
I'm about to extend Umbraco to handle a memberdatabase on about 5.000 members and scaleable up to 10.000+
The members will have about 8-10 extra properties than the normal (Username, LoginId, E-mail, password).
The members will be administrated on a protected location on the site and the data should be retrieved here from the database. So any hints on minimicing load times would be preferable.
I only have experience with handling the members in the Umbraco database, but my experince tells me that this is very heavy to work with if the members is 1.000+, so my question is basically - Do I win anything if I put the data in another database.
/cheers
Hi Soren,
Can you please provide the link where you read about som guidance and debate about what is Best practice on implementing an external membership database or not.
Thanks
Jigar
Hi Jigar.
There's no link - I want to start this debate here.
http://our.umbraco.org/wiki/how-tos/membership-providers
Umbraco implements the ASP.NET Membership API's, you should use that.
Whether or not you completely tie it into Umbraco for member management really comes down to the needs of your site administrators, but there's nothing to stop you from using the SqlMembershipProvider or anything else. Just tweak your web.config :)
I am looking into this too.
One thing is to use the Umbraco tables for members/users - another thing is how to store member properties/profiles.
So far I have come to the conclusion NOT to use Umbraco membertype to define the extra properties for members. The properties can only be accessed/modified (in an easy way) using the API.
I think I will implement a custom Profile provider for my member details. Custom here means NOT the default profile provider that is serializing data into one string in the ASPNET database. Instead I want a table provider like this: http://www.asp.net/downloads/sandbox/table-profile-provider-samples/
So far I dont know if I will store my users in the Members section?
Pro:
- Easy overview out-of-the-box
Cons:
- Members will be split from their custom properties
What do you think?
Thanks for the replies.
My concerns with using the standard Umbraco membership provider is speed. I know for a fact that extracting member data and properties in eg. listviews can be very slow if I exeed 1000 members. So my question is basically can I get better results if I use a seperat database to handle the members and use a SqlMembershipProvider ? A demo of setting this up would be preferable. I know how to work thru the API allready.
Can I maintain the members inside Umbraco and make properties or do I loose this functionality.
I posted an article on the instructions for configuring the SqlMembershipProvider here: Configuring SqlMembershipProvider in Umbraco 7.0.3. The main challenge is creating the controls in Umbraco for managing the roles and membership since those features are disabled once you roll over to the new provider. You will want to create custom controls for that. Sounds like a good use of AngularJS.
is working on a reply...