Se deben almacenar registros en el sitio en una tabla separada para los usuarios activos?

Question

Me pregunto sobre las mejores prácticas para el registro de usuarios. Me estoy inclinando hacia el almacenamiento de registros en el sitio en una mesa de inscripciones por separado y luego una vez que el registro ha sido confirmado por correo electrónico transferir los datos a la tabla de usuarios.

El beneficio de esto sería que lee de la tabla de usuarios no están llenas de inscripciones no activados. Otro beneficio es que el campo de correo electrónico (nombre de usuario) puede seguir siendo único en la tabla de usuarios, pero si intenta registrarse con una dirección de correo electrónico que usted no es dueño, el propietario de esa dirección de correo electrónico todavía será capaz de inscribirse en él como el campo de correo electrónico no será único en la tabla de registros.

Me pregunto si esto es una práctica común o si hay alguna razón esto no es una buena idea?

Answer 1

activado o no

No hay necesidad real para almacenar un usuario en una tabla diferente. Sólo almacenar todos los usuarios en una mesa, con un indicador booleano que indica si su activados o no. De vez en cuando ejecute una tarea programada para comprobar y ver si hay cuentas que están x días de edad y no activados y eliminarlos.

Correo electrónico

Así que presumiblemente va a activar el usuario desde la dirección de correo ¿verdad? También desea instalarlo de modo que si otro usuario haya introducido algún otro correo electrónico que otra persona podría inscribirse todavía correcta? Eso es en realidad bastante simple de hacer. En ese correo electrónico que se envía por error a ellos, sólo hay un enlace para eliminar ese correo electrónico de su base de datos porque, obviamente, no son ellos y que nunca van a activar la cuenta.

Pero lo que si el otro tipo sólo lo elimina?

A continuación, cuando se registran diles que ya tiene su dirección de correo y la oferta de enviar la activación de nuevo, esta dirección de correo también tendrá la opción de retirarlo de la base de datos.

o

Basta con retirar la cuenta más antigua de la base de datos. Lógico si la persona está tratando de activar una nueva cuenta y hay una vieja que nunca activado sólo puede eliminarlo.

Answer 2

Creo que habría más de la ingeniería.

Almacenar todos ellos en una mesa y programar una consulta SQL (todos los días) para eliminar las cuentas no Actived más de 30 días.

Answer 3

Hágase un favor y evitar que una sola tabla. Usted simplemente no va a tener suficientes registros abortados para los problemas de rendimiento que entran en juego (especialmente si se limpie después de 3 semanas).

Su justificación acerca de las direcciones de correo electrónico es tonta. Nadie es probable que obtenga su correo electrónico bloqueado por una inscripción falsa.

Answer 4

Puede haber un caso en el que desea dividir lógicamente las dos tablas: Si el proceso de registro hace una gran cantidad de información de usuario obligatorio sólo después de que haya confirmado la dirección de correo electrónico. Por ejemplo, si la tabla de registro en espera terminaría con sólo unas pocas columnas, como el correo electrónico y la clave de activación, mientras que sus usuarios tabla tiene muchas columnas adicionales, tales como nombre de usuario, nombre, apellido, dirección postal, etc.

La división podría tener sentido en ese caso, ya que sería capaz de declarar los NOT NULL columnas.

Aparte de eso, sin embargo, tengo que estar de acuerdo con la mayoría de las otras respuestas; suena como la optimización prematura a mí. Varias tablas con la misma estructura es una fuerte señal de advertencia que doin del ur mal. no es definitiva, pero una fuerte advertencia.

Answer 5

Estoy de acuerdo con esta práctica para la separación de las preocupaciones razones: Un "proceso de registro" y "Cuentas de usuario" son dos conceptos separados

.

La mesa de registro se utiliza para guardar el estado del "proceso de registro". Una vez finalizado el proceso (una vez que el correo electrónico se valida), "salida" del proceso sería una nueva "cuenta de usuario". Si el proceso falla (por ejemplo, "tiempo de espera" después de que el usuario no puede confirmar su correo electrónico para 1 mes), no hay impacto en la "cuenta de usuario" concepto.

Como se ha dicho en otra respuesta, esto puede ser a través de la ingeniería, en algunos casos, pero también puede ser una forma útil de enapsulate complejidad de estos dos conceptos distintos. También puede ser visto como contradiciendo los principios de normalización, pero entonces creo que usted tiene que elegir una compensación entre la encapsulación y la normalización dependiendo de su contexto.