¿Por qué la separación de los datos de usuario y de perfil se considera buena?

Question

He estado leyendo esto question y siento que no estoy de acuerdo con la declaración Separation of user and profile data is a nice touch.

Según lo veo, los datos de perfil, como, p. Ej. país o lo que pertenece en el objeto de usuario, mientras que la separación de dichos datos en el perfil conduce a la creación de un nuevo objeto (y una tabla) con una relación de 1 a 1 con el objeto del usuario. ¿Se considera dicha separación una buena práctica simplemente por razones estéticas? (Usted ve solo los datos de entrada del usuario en una tabla y los datos generados están en otra)

Answer 1

Bueno, eso solo si supone que el usuario y el perfil tienen una relación de 1 a 1.

Si se garantiza que siempre será así, la razón de la separación puede ser puramente estética, sin embargo, puede haber razones de rendimiento para separarlos.

Por ejemplo, los datos de perfil se puede acceder por otros usuarios, a menudo se pueden almacenar en caché sin mucha consideración de nulidad rápida, etc.

Ellos son conceptualmente diferentes tipos de datos - incluso si tienen 1-a-1 relación. Nunca almacenaría en caché los detalles de inicio de sesión del usuario, pero no lo expondría de forma programática a módulos que simplemente requieren datos de perfil.

Esa es la razón por la que se puede garantizar que la relación de 1 a 1 se mantenga. ¿Puede?

Si permite múltiples credenciales de inicio de sesión (o múltiples métodos de inicio de sesión) por usuario, ahora se vuelve más interesante. Por ejemplo, las sesiones basadas en cookies a menudo se almacenan en un almacenamiento volátil en el lado del servidor (rara vez es necesario que persistan esos datos). ¿Tendría esa información apuntando al objeto del usuario, o al objeto del perfil?

Puede tener una relación unidireccional: hay un puntero de Usuario a Perfil, pero no de Perfil a Usuario. De esta manera, los módulos que contienen los datos del perfil no pueden cambiar los detalles de inicio de sesión.

Por último, ¿qué ocurre si usa una solución como Facebook, que permite múltiples correos electrónicos de inicio de sesión por usuario, y además inicia sesión a través de OpenID y a través de una aplicación de iPhone/Android? ¿Aceptarías entonces que Perfil y Usuario siguen siendo los mismos?

Answer 2

Pros:

1. puede cambiar libremente esquema de tabla de perfil y no se molestan si se rompe usuario.
2. Puede reutilizar la autenticación/lógica de autorización en otras aplicaciones.
3. Puede vincular un usuario a diferentes perfiles e incluso a otras aplicaciones.
4. Mejor rendimiento debido a pequeñas cantidades de datos en la entidad de usuario (se aplica al almacenamiento de base de datos, donde menos columnas en la tabla es mejor) durante operaciones de autenticación y otras operaciones de usuario que no requieren datos de perfil.

Contras:

1. Una mesa más DB u otra entidad de datos de almacén de perfiles
2. Hay que mantener la relación entre los datos de perfil y de usuario.
3. Más código.
4. Se puede producir una caída de rendimiento al acceder a los datos del perfil.

Por ejemplo, Django (Python web framework) proporciona el mecanismo de autenticación y puede agregar su propio mecanismo de perfil.

Generalmente, si el perfil es pequeño y nunca estará sujeto a modificaciones, puede guardarlo junto con los datos del usuario. Si el esquema de perfil se puede modificar en el futuro o si contiene muchos datos, es mejor separar el usuario y el perfil.

Answer 3

Hay algunas razones que se me ocurren para dividir los datos de usuario:

1. La separación de la autorización de la información. Esto es algo que recomendaría encarecidamente. Una vez que el usuario está autenticado, solo mira el perfil del usuario. Al separar la parte de autorización, puede pasar fácilmente de un inicio de sesión con contraseña, agregar Facebook Connect, autenticación OpenID, etc. sin tener que hacer ningún cambio en los objetos del perfil de usuario.
2. Separación de datos públicos y privados. En las bases de datos de alta seguridad, es posible que desee encriptar los datos privados con claves privadas (para que solo el usuario pueda leer los datos), y al mismo tiempo poder acceder a los datos públicos como otro usuario.
3. Por razones de rendimiento. Si tiene grandes cantidades de datos en el usuario, es posible que desee colocar datos que rara vez se accede por sí solo, de modo que los índices se pueden optimizar para datos que a menudo se buscan.

Answer 4

Si tiene una API pública (como, por ejemplo, twitter o facebook), le gustaría devolver solo los detalles del usuario, y no el objeto del usuario (que contiene los datos protegidos). Eso se puede hacer teniendo entidades separadas o teniendo un DTO.

Answer 5

Para mí, el usuario es: Inicio de sesión (Nombre de usuario), Contraseña, Rol y se utiliza para hacer todo lo relacionado con la seguridad.

El "perfil" es información adicional para el usuario, que debe colocarse en un objeto separat.

Y tener en cuenta: en algunos casos, un usuario puede tener más de un perfil ...

Answer 6

Principalmente porque los datos de perfil no es necesario si se quiere simplemente saber quién creó una cierta entidad. El único lugar real que necesita un perfil de usuario es principalmente cuando el sistema desea personalizar algo para ese usuario cuando están en el sistema. Imagine que el perfil tiene el color favorito de los usuarios, esto es irrelevante para muchos o todos los demás usos de la aplicación.