2009-09-28 19 views

Respuesta

10

Es para separar la gestión de identidad/autenticación de la gestión de membresía. La tabla de usuarios "grande" es el repositorio de identidad real; por ejemplo, si desea usar SQL para almacenar sus datos de identidad, todo va aquí. Pero es posible que desee utilizar alguna otra fuente, por ejemplo, Active Directory, para que sea su repositorio de identidades. En su lugar, valida la identidad y la autenticación, pero aún necesita tener alguna forma de unir los datos de rol/membresía basados ​​en SQL con los datos de identidad basados ​​en AD. Ahí es donde entra la tabla más pequeña: información suficiente para mantener esas relaciones.

+0

Estoy abandonando la membresía de asp.net porque no necesito muchas de las tablas y como he hecho algunas cosas, he hecho que todo el método incorporado sea inútil. Así que estoy tratando de averiguar si debo dividir los datos de esta manera o pegarlos en una sola tabla. ¿Cuál es el enfoque recomendado? – chobo2

+1

@ Chobo2 difícil de decir sin conocer sus necesidades. Sin embargo, diría que si el proveedor de ASP.NET hace todo lo que necesita y mucho que no necesita, puede querer quedarse con él. Construir el suyo es un costo que podría estar gastando en cosas mejores. Pero, si necesita alguna funcionalidad específica, primero diseñe su proveedor según sus necesidades. –

2

Es para asegurar múltiples aplicaciones desde una sola base de datos de usuario; aspnet_membership tiene UserId y ApplicationId, por lo que cada usuario puede tener una contraseña diferente para múltiples aplicaciones (y también estar bloqueado de una aplicación, pero no de otra).

+2

Eso es cierto, pero la otra tabla también contiene esa información, por lo que no ha respondido por qué existen las dos tablas diferentes. –

Cuestiones relacionadas