title: Using ASP.NET SQL Membership Provider, how do I store my own per-user data?
body: <p>I'm using the ASP.NET SQL Membership Provider. So, there's an <code>aspnet_Users</code> table that has details of each of my users. (Actually, the <code>aspnet_Membership</code> table seems to contain most of the actual data).</p>
  
  <p>I now want to store some per-user information in my database, so I thought I'd just create a new table with a <code>UserId</code> (GUID) column and an FK relationship to <code>aspnet_Users</code>. However, I then discovered that I can't easily get access to the <code>UserId</code> since it's not exposed via the membership API. (I know I can access it via the <code>ProviderUserKey</code>, but it seems like the API is abstracting away the internal <code>UserID</code> in favor of the <code>UserName</code>, and I don't want to go too far against the grain).</p>
  
  <p>So, I thought I should instead put a <code>LoweredUserName</code> column in my table, and create an FK relationship to <code>aspnet_Users</code> using that. Bzzzt. Wrong again, because while there is a unique index in <code>aspnet_Users</code> that <em>includes</em> the <code>LoweredUserName</code>, it also includes the <code>ApplicationId</code> - so in order to create my FK relationship, I'd need to have an <code>ApplicationId</code> column in my table too. </p>
  
  <p>At first I thought: fine, I'm only dealing with a single application, so I'll just add such a column and give it a default value. Then I realised that the <code>ApplicationId</code> is a GUID, so it'd be a pain to do this. Not <em>hard</em> exactly, but until I roll out my DB I can't predict what the GUID is going to be.</p>
  
  <p>I feel like I'm missing something, or going about things the wrong way. What am I <em>supposed</em> to do?</p>