ASP.NET Proveedor de membresía personalizado para aplicaciones muy grandes

Question

Tengo que encontrar una solución de membresía para un sitio web muy grande. El sitio se construirá utilizando ASP.NET MVC 2 y una base de datos MS SQL2008.

El proveedor de Membresía actual parece una GRAN exageración, hay demasiada funcionalidad.

Todo lo que deseo almacenar es un correo electrónico/contraseña e información básica de perfil como Nombre/Apellido, Número de teléfono. Solo necesitaré 2 roles, administradores & usuarios.

¿Cuáles son sus recomendaciones sobre este tipo de escenario, considerando que podría haber millones de usuarios registrados? ¿Qué usa StackOverflow?

he utilizado la API de afiliación existente mucho en el pasado y lo han extendido para almacenar información adicional, etc. Pero no hay tablas tales como

aspnet_Applications 
aspnet_Paths 
aspnet_SchemaVersions 
aspnet_WebEvent_Events 
aspnet_PersonalizationAllUsers 
aspnet_PersonalizationPerUser 

que son extremadamente redundante y nunca he encontrado uso para.

Editar
Solo para aclarar algunas otras redundancias después de la respuesta de @ drachenstern, también hay columnas adicionales que no tengo ningún uso para en la tabla de miembros/usuarios, pero que se sumaría a la carga útil de cada selección/insertar declaraciones

1. MobilePIN
2. PasswordQuestion/PasswordAnswer (Voy a hacer la recuperación de contraseñas de correo electrónico basados)
3. IsApproved (usuario siempre será aprobada)
4. comentario
5. MobileAlias ​​
6. Nombre de usuario/LoweredUsername (o Email/LoweredEmail) [email ES el nombre de usuario solo necesita 1 de estos]

Además, he oído que los GUID no son tan rápidos, y preferiría tener enteros en su lugar (como Facebook lo hace) que también quedarían expuestos públicamente.

¿Cómo hago para crear mi propia membresía Proveedor, la reutilización de algunas de las APIs de miembros (validación, el cifrado de contraseñas, cookies de inicio de sesión, etc.) pero sólo con tablas que cumplen mis necesidades?

Los enlaces a los artículos y las implementaciones existentes son muy bienvenidos, mis búsquedas de Google han arrojado algunos ejemplos muy básicos.

Gracias de antemano
Marko

Answer 1

@Marko Definitivamente puedo entender que el sistema de membresía estándar puede contener más funcionalidad de la que necesita, pero la verdad es que realmente no va a importar. Hay partes del sistema de membresía que no va a usar, así como hay partes de .Net que no va a usar. Hay muchas cosas que .Net puede hacer que nunca, nunca usará, pero no pasará por .Net y eliminará esa funcionalidad, ¿verdad? Por supuesto no. Tienes que concentrarte en las cosas que son importantes para lo que estás tratando de lograr y trabajar desde allí. No te dejes atrapar en la parálisis del análisis. Perderá su tiempo, hará girar sus ruedas y no terminará con nada mejor que lo que ya ha sido creado para usted. Ahora Microsoft se equivoca a veces, pero consiguen muchas cosas bien. No tiene que aceptar todo lo que hace para lograr sus objetivos, solo tiene que entender qué es importante para sus necesidades.

En cuanto a los Guids y los ints como claves principales, déjenme explicarles algo. Hay una diferencia crucial entre una clave principal y un índice agrupado. Puede agregar una clave principal Y un índice agrupado en columnas que no forman parte de la clave principal. Eso significa que si es más importante tener sus datos ordenados por un nombre (o lo que sea), puede personalizar su índice agrupado para reflejar exactamente lo que necesita sin que afecte su clave principal. Permítanme decirlo de otra manera: una clave principal y un índice agrupado NO son uno en el mismo. Escribí una publicación de blog sobre cómo agregar un índice agrupado y luego una clave principal para sus tablas. El índice agrupado ordenará físicamente las filas de la tabla de la forma en que las necesita y la clave principal aplicará la integridad que necesita. Echa un vistazo a la publicación de mi blog para ver exactamente cómo puedes hacerlo.

Aquí está el enlace - http://iamdotnetcrazy.blogspot.com/2010/09/primary-keys-do-not-or-should-not-equal.html.

Es realmente simple, solo agrega el índice agrupado PRIMERO y luego agrega la clave primaria SEGUNDO. Debe hacerse en ese orden o no podrá hacerlo. Esto supone, por supuesto, que está utilizando el servidor Sql. La mayoría de las personas no se dan cuenta de esto porque SQL Server creará un índice agrupado en la clave principal por defecto, pero todo lo que tiene que hacer es añadir el índice agrupado primero y luego añadir la clave principal y que será bueno para ir. Usar ints como clave principal puede volverse MUY problemático a medida que su base de datos y sistema de servidor se amplían. Sugiero usar Guids y agregar el índice agrupado para reflejar la forma en que realmente necesita almacenar sus datos.

Ahora, en resumen, solo quiero decirte que vayas a crear algo genial y no te empantanes con detalles superficiales que no te darán suficiente ganancia de rendimiento como para que realmente importen. La vida es demasiado corta. Además, recuerde que su sistema solo puede ser tan rápido como su código más lento. Así que asegúrese de mirar las cosas que REALMENTE Toman mucho tiempo y cuiden de ellas.

Y una cosa más adicional. No puede tomar todo lo que ve en la web a su valor nominal. La tecnología cambia con el tiempo. A veces, puede ver una respuesta a una pregunta que alguien escribió hace mucho tiempo y que ya no es relevante hoy. Además, la gente va a responder a las preguntas y darle información sin haber hecho probaron lo que están diciendo a ver si es verdad o no. Lo mejor que puede hacer por su aplicación es hacer una prueba de esfuerzo muy bien. Si está utilizando ASP.Net MVC, puede hacer esto en sus pruebas. Una cosa que puede hacer es agregar un bucle for que agrega usuarios a su aplicación en su prueba y luego probar cosas. Esa es una idea. Hay otras formas.Solo tiene que esforzarse un poco para diseñar bien sus pruebas o al menos lo suficientemente bien para sus propósitos.

¡Buena suerte para usted!

Answer 2

el proveedor de pertenencia actual parece una exageración GRANDE, hay demasiada funcionalidad.

Todo lo que deseo almacenar es un correo electrónico/contraseña e información básica de perfil como Nombre/Apellido, Número de teléfono. Solo necesitaré 2 roles, administradores & usuarios.

Entonces simplemente use esa parte. No va a utilizar las piezas que no usa, y es posible que necesite esas otras partes más adelante. Las clases ya están presentes en el marco de .NET, por lo que no tiene que proporcionar licencias ni nada.

El tamaño de la base de datos es bastante pequeño, y si lo haces, y dejas aspnetdb para sí mismo, entonces realmente no estás tomando nada de tus otras bases de datos.

¿Tiene una razón de peso para utilizar un componente de terceros OVER lo que está en el marco ya?

---

EDITAR:

también hay columnas adicionales que he no va a usar en la tabla Membership/usuarios, pero que añadirían a la carga útil de cada Seleccionar/insertar declaraciones

MobilePIN PasswordQuestion/PasswordAnswer (Voy a hacer la recuperación de la contraseña de correo electrónico basados) IsApproved (usuario siempre será aprobada ) Comentario MobileAlias ​​ nombre de usuario/LoweredUsername (o Email/LoweredEmail) [El correo electrónico es el nombre de usuario solo necesita 1 de estos]

Parece que está intentando microoptimize. Aprobar cadenas vacías es prácticamente sin costo (está bien, está ahí, pero tienes que hacer un perfil para saber cuánto te está costando. No será TANTO por usuario). Ya no utilizamos rutinariamente todos estos campos en nuestras aplicaciones, pero utilizamos el sistema de membresía sin un impacto perjudicial mensurable.

Además, he oído que los Guid no son tan rápidos, y preferirían tener enteros en su lugar (como Facebook lo hace) que también quedarían expuestos públicamente.

He oído que cookiemonster le gusta las cookies. De nuevo, sin crear perfiles, no sabes si eso es perjudicial. Por lo general, las personas usan los GUID porque quieren que sean absolutamente (hasta cierto grado de absoluta) únicos, sin importar cuándo se crean. El costo de generarlo UNA VEZ por usuario no es tan pesado. No cuando ya estás creando una nueva cuenta.

---

Desde le fijan absolutamente en la creación de un MembershipProvider desde cero, aquí hay algunas referencias:

http://msdn.microsoft.com/en-us/library/system.web.security.membershipprovider.aspx

http://www.4guysfromrolla.com/articles/120705-1.aspx

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

http://www.amazon.com/ASP-NET-3-5-Unleashed-Stephen-Walther/dp/0672330113

Stephen Walther entra en detalles sobre eso en su libro y es una buena referencia para que usted tenga como es.

Answer 3

Mi recomendación sería que lo comparen. Agregue tantos registros como cree que tendrá en producción y envíe una cantidad similar de solicitudes como lo haría en producción y vea cómo funciona para su entorno.

Supongo que estaría bien, la sobrecarga de la que está hablando sería insignificante.