tabla de usuarios temporales o tabla de usuarios legítimos?

Question

Tengo una aplicación web independiente que permite a los usuarios se registren para eventos. En mi base de datos, tengo una tabla con el t_events_applicants t_events_applications.user_id columna con una restricción de clave externa vinculada a la columna de t_users.user_id. Así que esto significa que sólo los usuarios que se hayan registrado con mi aplicación web pueden inscribirse para los eventos de mi aplicación web.

Mi cliente le gustaría ahora permitirá a los usuarios no registrados, los usuarios que no tienen una entrada en mi mesa t_user, para inscribirse en eventos. Estos usuarios no registrados sólo tienen que proporcionar su nombre y dirección de correo electrónico para registrarse en eventos.

¿Debo crear una tabla con el nombre t_temporary_user columnas y correo electrónico y luego eliminar la restricción FK t_events_applicants.user_id? O debo añadir usuarios no registrado a la mesa t_user y luego añadir una columna llamada t_user.type donde tipo puede ser registrados "o 'no registrado'?

¿Cómo decidir qué enfoque para ir con?

Muchas veces, me vacila con uno u otro enfoque. Me pregunto, "¿Qué pasa si en un momento posterior, un usuario temporal se le permite convertirse en un usuario registrado totalmente, entonces tal vez debería tener solamente una mesa t_user. Pero entonces yo también no sentirse bien acerca de almacenar una gran cantidad de usuarios temporales en t_user ".

Answer 1

¿No sería que, básicamente, ser un papel?

Crear una tabla de usuarios, darles una serie de funciones (muchos a muchos users_roles).
En la tabla de funciones, deberá añadir una función que permite registrar para eventos y funciones de los diversos derechos sobre el resto de su sitio web.
De esta manera es fácil de promover eventos sólo para los usuarios a las de la ley a los usuarios completos (añadir los papeles correctos) y será posible añadir otras cosas más tarde (otros eventos especiales, suscripciones, etc.).
Lo más probable es que ya tiene un sistema de este tipo en lugar de todos modos ..

Answer 2

Me gustaría ir con el segundo enfoque: añadirlos en la misma mesa, pero con la columna Tipo. Si crea dos tablas de usuario, tendrá que comprobar siempre tanto para encontrar un usuario, etc, con dos mesas, ¿cómo tener una restricción por parte del usuario a algo que ellos crean? Debe ser sencillo, que son un usuario, simplemente un tipo diferente.

Si usted tiene una mesa CreateDate o la fecha en lastlogin los usuarios (o algún otro), se puede eliminar usuarios temporales después de una cierta cantidad de tiempo.

Answer 3

Parece que los usuarios registrados frente a los usuarios no registrados se ha convertido en una falsa distinción dadas las nuevas necesidades del sistema. Me gustaría mantener a todos juntos en una sola tabla. Mantener la información de registro en el sitio en una tabla separada. Ni siquiera necesita una columna de tipo en el cuadro combinado ya que se puede determinar si el usuario está registrado con un JOIN a la mesa de registro en el sitio.