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.
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
@ 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. –