c# - What is meaning of multiply a table to self and get one field? -

this source code of webmatrix.webdata.simplemembershipprovider.gethashedpassword:

   private string gethashedpassword(idatabase db, int userid)            {                var pwdquery = db.query(@"select m.[password] " +                                        @"from " + membershiptablename + " m, " + safeusertablename + " u " +                                        @"where m.userid = " + userid + " , m.userid = u." + safeuseridcolumn).tolist();                // review: should 1 match, should throw if > 1?                if (pwdquery.count != 1)                {                    return null;                }                return pwdquery[0].password;            } 

you can find on http://aspnetwebstack.codeplex.com/sourcecontrol/latest#src/webmatrix.webdata/simplemembershipprovider.cs

and .net reflector check webmatrix.webdata.dll

if check code, can see user table multiply self , password field running query, in simple way this:

select m.password [users] m, [users] u  m.[userid] = 1 , m.userid = u.userid 

if @ difference between membershiptablename , safeusertablename:

internal static string membershiptablename {     { return "webpages_membership"; } }  private string safeusertablename {     { return "[" + usertablename + "]"; } }  // represents user table app public string usertablename { get; set; } 

so safeusertablename [usertablename] can set separately whereas membershiptablename always "webpages_membership". query resolves (assuming usertablename set "users", userid "1"):

select m.[password] webpages_membership m, [users] u m.userid = 1 , m.userid = u.[userid] 

i think data separated between 2 different tables , helps ensure it's getting correct values corner cases. specifically, suppose helps ensure not retrieve hashed password webpages_membership user no longer exists in [users] (though expect both entries wiped if user removed system, perhaps it's double-check avoid malicious use)

edit: perhaps it's allow multiple "users" tables used , share same membership one/many applications. different "users" tables might keep different information different applications, "webpages_membership" maintains global set of users/passwords across all applications. when membershipprovider setup specific application, prevents access hashed password user doesn't belong different application.

that is, user belongs applicationa, , applicationb, not applicationc. each application has own "users" table. membership provider in applicationa/applicationb can access hashed password user, applicationc's membership provider cannot. later on, user may "link" account applicationc @ point entry added applicationc.users table , gethashedpassword returns valid result.