Debo usar el nombre de usuario o la identificación del usuario para hacer referencia a los usuarios autenticados en ASP.NET

Question

Por lo tanto, en mi sitio web de aprendizaje simple, utilizo el sistema de autenticación incorporado de ASP.NET.

Estoy añadiendo ahora una tabla de usuario para guardar cosas como su postal, fecha de nacimiento, etc. Mi pregunta es:

1. En la nueva tabla, debe ser la clave del nombre de usuario (la cadena) o el usuario ID que es ese número de GUID buscando que usan en el asp_ tables.
2. Si la mejor práctica es usar ese feo guid, ¿alguien sabe cómo conseguirlo? parece no ser accesible tan fácilmente como el nombre (System.Web.HttpContext.Current.User.Identity.Name)
3. Si sugiere que no utilizo ninguno (ni los campos guid ni userName provistos por la autenticación ASP.NET) entonces, ¿cómo lo hago con la autenticación ASP.NET? Una opción que me gusta es usar la dirección de correo electrónico del usuario como inicio de sesión, pero ¿cómo hacer que el sistema de autenticación ASP.NET use una dirección de correo electrónico en lugar de un nombre de usuario? (O no hay nada que hacer allí, es sólo yo decidir que "sé" nombre de usuario es en realidad una dirección de correo electrónico

Tenga en cuenta:?

• No estoy pidiendo sobre cómo obtener un GUID en .NET, yo sólo me refiero a la columna de ID de usuario en el asp_ tables como GUID.
• el nombre de usuario es único en la autenticación de ASP.NET.

Answer 1

se recomienda usar el nombre de usuario como la clave principal en la tabla si el nombre de usuario va a ser única, hay algunas buenas razones para hacer esto:

1. La clave primaria habrá un índice agrupado y así buscar los detalles de los usuarios a través de su nombre de usuario será muy rápido.
2. Se detendrá duplicar nombres de usuario aparezcan
3. Usted no tiene que preocuparse de usar dos pedazos diferentes de información (nombre de usuario o GUID)
4. Esto hará que la escritura de código mucho más fácil porque de no tener que las operaciones de búsqueda dos bits de información.

Answer 2

se debe utilizar una identificación única, el GUID que mencionas o algunos otros auto gener llave atada Sin embargo, este número nunca debería ser visible para el usuario.

Una gran ventaja de esto es que todo el código puede funcionar en la identificación del usuario, pero el nombre del usuario no está realmente vinculado a ella. Luego, el usuario puede cambiar su nombre (que he encontrado útil en los sitios). Esto es especialmente útil si usa la dirección de correo electrónico como el inicio de sesión del usuario ... que es muy conveniente para los usuarios (entonces no tienen que recordar 20 ID en caso de que su ID de usuario común sea popular).

Answer 3

Estoy de acuerdo con Mike Stone. También sugeriría solo usar un GUID en caso de que vaya a rastrear una gran cantidad de datos. De lo contrario, bastará con una simple columna entera de incremento automático (Id).

Si necesita el GUID, .NET es lo suficientemente agradable que usted puede conseguir uno por un simple ...

Dim guidProduct As Guid = Guid.NewGuid() 

o

Guid guidProduct = Guid.NewGuid(); 

Answer 4

Se debe utilizar la ID de usuario. Es la propiedad ProviderUserKey de MembershipUser.

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 5

Yo usaría un ID de usuario. Si desea utilizar un nombre de usuario, va a hacer que la función "cambiar el nombre de usuario" sea muy costosa.

Answer 6

Si vas a utilizar LinqToSql para el desarrollo, te recomendaría usar un int como clave principal. He tenido muchos problemas cuando tuve relaciones creadas a partir de campos que no son Int, incluso cuando el campo nvarchar (x) tenía restricciones para convertirlo en un campo único.

No estoy seguro de si esto es un error conocido en LinqToSql o qué, pero he tenido problemas con él en un proyecto actual y tuve que intercambiar PK y FK en varias tablas.

Answer 7

Estoy de acuerdo con Mike Stone también. Recientemente, mi empresa implementó una nueva tabla de usuarios para clientes externos (a diferencia de los usuarios internos que se autentican a través de LDAP). Para los usuarios externos, elegimos almacenar el GUID como clave principal, y almacenar el nombre de usuario como varchar con restricciones únicas en el campo de nombre de usuario.

Además, si va a almacenar el campo de contraseña, le recomiendo que guarde la contraseña como un binario salado y hash en la base de datos. De esta forma, si alguien pirateara su base de datos, no tendría acceso a las contraseñas de sus clientes.

Answer 8

Yo usaría un número de incremento automático generalmente un int.

Desea mantener el tamaño de la clave lo más pequeño posible. Esto mantiene su índice pequeño y también beneficia a las claves externas. Además, no está conectando estrechamente el diseño de los datos a los datos de los usuarios externos (esto también se aplica al GUID de aspnet).

En general, los GUID no son buenas claves primarias ya que son grandes y pueden producirse insertos en cualquier página de datos potencialmente dentro de la tabla en lugar de en la última página de datos. La principal excepción a esto es si está ejecutando bases de datos replicadas de mutilple. Los GUID son muy útiles para las claves en este escenario, pero supongo que solo tiene una base de datos, así que esto no es un problema.

Answer 9

Estoy de acuerdo con Palmsey, Aunque parece que hay un pequeño error en su código:

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString()); 

debería ser

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString()); 

Answer 10

yo diría que el uso del ID de usuario por lo que los nombres de usuario todavía se puede cambiar sin afectar la clave primaria. También establecería que la columna de nombre de usuario sea única para detener los nombres de usuario duplicados.

Si principalmente va a buscar un nombre de usuario en lugar de un ID de usuario, haga que el nombre de usuario sea un índice agrupado y establezca que la clave principal no esté agrupada. Esto le proporcionará el acceso más rápido cuando busque nombres de usuario, si es que principalmente va a buscar UserIds y luego deje esto como el índice agrupado.

Editar: Esto también se ajustará mejor con las tablas de membresía actuales de ASP.Net ya que también usan el ID de usuario como clave principal.

Answer 11

Usaría el guid en mi código y como ya mencioné una dirección de correo electrónico como nombre de usuario.Después de todo, ya es único y memorable para el usuario. Tal vez incluso abandonar el guid (v. Discutible).

Alguien mencionó usar un índice agrupado en el GUID si esto se estaba utilizando en su código. Yo evitaría esto, especialmente si los INSERT son altos; el índice se reconstruirá cada vez que INSERTAR un registro. Los índices agrupados funcionan bien en ID de incrementos automáticos porque solo se anexan nuevos registros.

Answer 12

Esto es viejo, pero sólo quiero gente que parece que este tenga en cuenta algunas cosas: la base de datos de miembros

1. La Red PEA se optimiza cuando se trata de acceder a los registros de usuarios. La búsqueda de índice agrupado (óptima) en el servidor sql se usa cuando se busca un registro utilizando loweredusername y applicationid. Esto tiene mucho sentido ya que solo tenemos el nombre de usuario proporcionado para continuar cuando el usuario envía sus credenciales por primera vez.

2. El ID de usuario guid dará un tamaño de índice más grande que un int pero esto no es realmente significativo porque a menudo solo recuperamos 1 registro (usuario) a la vez y en términos de fragmentación, el número de lecturas supera con creces cantidad de escrituras y ediciones en la tabla de usuarios: las personas simplemente no actualizan esa información con tanta frecuencia.

3. La secuencia de comandos regsql que crea las tablas de miembros aspnet puede editarse para que en lugar de utilizar NEWID como valor predeterminado para userid, pueda usar NEWSEQUENTIALID() que ofrezca un mejor rendimiento (he perfilado esto).

4. Perfil. Alguien que cree un "nuevo sitio web de aprendizaje" no debería tratar de reinventar la rueda. Uno de los sitios web en los que he trabajado utilizaba una versión de las tablas de membresía aspnet (excluyendo el horrible sistema de perfiles) y la tabla de usuarios contenía casi 2 millones de registros de usuarios. Incluso con un número tan alto de registros, las selecciones seguían siendo rápidas porque, como dije al principio, los índices de la base de datos se centran en loweredusername + applicationid para peform indexar búsqueda de estos registros y, en términos generales, si sql está haciendo una búsqueda de índice agrupado para encontrar 1 registro, no tiene ningún problema, incluso con un gran número de registros siempre que no agregue columnas a las tablas y comience a retirar demasiados datos.

5. Preocuparse por un guid en este sistema, para mí, basado en el rendimiento real y la experiencia del sistema, es una optimización prematura. Si tiene un int para su ID de usuario pero el sistema realiza consultas subóptimas debido a su diseño de índice personalizado, etc., el sistema no se escalará bien. Los chicos de Microsoft hicieron un trabajo generalmente bueno con el dominio de membresía aspnet y hay muchas cosas más productivas para enfocar que cambiar el ID de usuario a int.