(ASP.NET MVC 5, EF6, VS2013)

Estoy tratando de averiguar cómocambia el tipo del campo "Id" de cadena a int en el tipo:

Microsoft.AspNet.Identity.EntityFramework.IdentityUser

para que las nuevas cuentas de usuario se asocien con un ID entero en lugar de un GUID. Pero parece que esto será más complicado que simplemente agregar una nueva propiedad de Id con el tipo int en mi clase de usuario derivado. Echa un vistazo a esta firma de método:

(de Assembly Microsoft.AspNet.Identity.Core.dll)

public class UserManager<TUser> : IDisposable where TUser : global::Microsoft.AspNet.Identity.IUser
  {
  ...
  public virtual Task<IdentityResult> AddLoginAsync(string userId, UserLoginInfo login);
  ...
  }

Así que parece que hay otros métodos integrados en el marco de identidad de ASP.NET que requieren que userId sea una cadena. ¿Tendría que volver a implementar estas clases también?

Una explicación de por qué no quiero almacenar GUID para identificadores en la tabla de usuarios:

-Habrá otras tablas que relacionan los datos con la tabla de usuarios a través de una clave externa. (Cuando los usuarios guardan contenido en el sitio). No veo ninguna razón para usar el tipo de campo más grande y gastar espacio de base de datos adicional sin ventajas claras. (Sé que hay otras publicaciones sobre el uso de GUIDs vs int ids, pero parece que muchos sugieren que los int ids son más rápidos y usan menos espacio, lo que me deja sin dudas).

-Pienso exponer un punto final de descanso para permitir a los usuarios recuperar datos sobre un usuario en particular. Yo creo que:

/users/123/name

es más limpio que

/users/{af54c891-69ba-4ddf-8cb6-00d368e58d77}/name

¿Alguien sabe por qué el equipo de ASP.NET decidió implementar las ID de esta manera? ¿Estoy siendo miope al tratar de cambiar esto a un tipo int? (Quizás hay beneficios que estoy perdiendo).

Gracias...

-Ben