score:3

Accepted answer

Not an expert in this, but what my apps typically do is to use a foreign key (with Index) from my own Users table to the Membership Users table using the Guid field with the Membership. This then allows me to do queries using Linq like:

 var query = from myUser in MyUsers
            join aspUser in aspnet_Users on myUser.UserId equals aspUser.UserId
            join usersInRole in aspnet_UsersInRoles on aspUser.UserId equals usersInRole.UserId
            join role in aspnet_Roles on usersInRole.RoleId equals role.RoleId
            where role ...
            select new { ... };

(Or you can use dot-form like myUser.AspUser.Roles.Role to let the ORM generate the joins if you prefer)

For performance, it's good to watch the SQL trace occasionally - make sure you're not making too many SQL round-trips for each logical step in code.

Hope that helps a bit.


Update - in answer to your questions about "should you even do that", I think "yes" but there are other options available - e.g. you can use Profile fields - see Step 6 in this great walkthrough - http://www.4guysfromrolla.com/articles/120705-1.aspx

score:0

We have created EntityFramework entities for all of the AspNet membership tables, this lets us query them like any other entity.

Not sure if it is what your after but may help


Related Articles