Perfil de usuario: me conviene hacer dos tablas o solo una con todos los datos?

[reborn]

Hola,

estoy creando un perfil de usuario y quisiera saber q es mas conveniente, si hacer una tabla para usuarios y otra para perfil o sacar todo de una misma tabla (usuarios)?

YO lo veo mas facil/accesible haciendo una sola tabla en donde tenga:
id
username
pass
nombre
apellido
email
ciudad
etc...

Gracias

pd: con perfil me refiero a mostrar sus datos, como en una red social

[evolutionrgm]

Si es lo mas recomendable , es realizar solo una tabla y evitar duplicidad de datos .. te recomiendo que revises algo acerca de las normalizacion de tablas en las cuales te puede resolver . algunas dudas que tienes ahora :)

[reborn]

Iniciado por evolutionrgm

Si es lo mas recomendable , es realizar solo una tabla y evitar duplicidad de datos .. te recomiendo que revises algo acerca de las normalizacion de tablas en las cuales te puede resolver . algunas dudas que tienes ahora :)

Ok.
Muchas gracias por tu respuesta

[gnzsoloyo]

El tema no pasa por duplicidad de datos. Si los datos se duplican (eso sería provocar inconsistencia de datos), lo que tendrías sería un error de normalización.
La primera clave para resolver tu pregunta es determinar si hay un conjunto de 1+N datos que sean opcionales, es decir que puedan o no existir en todos los casos. Si existe un conjunto identificable de datos referidos a un determiando concepto del usuario (direcciones, por ejemplo, teléfonos, familiares), ese subconjunto debe separarse en una tabla dependiente.
Pero en este caso lo que debes definir es si es o no opcional. Si los datos fueran mandatorios (obligatorios), y su relacion fuese 1:1, no tiene ningún sentido separarlos, a excepción de simplicidad estructural y perfomance para las consultas.
En este último caso se refiere a que aún dentro de la misma entidad, tienes N datos que siempre se consultan, y M datos que se consultan esporadicamente y se modifican rara vez. Dada esa situación, por cuestiones de performance podría ser conveniente separarlos.

Una cosa que debes entender es que existen infinitas formas de resolver el diseño de datos para la misma aplicación, y que dos analistas, trabajando con el mismo sistema, con iguales requisitos y para el mismo cliente, pueden plantearte dos diseños completamente distintos e interexcluyentes (uno no incluye al otro e incluso lo contradirce), sin que eso signifique que uno es correcto y el otro no.
Todo depende de cómo se analiza. No existen modos "mejores", no existe en este ámbito "la mejor forma". Lo que sí existen son métodos para llegar a resultados optimizados, pero los resultados varían de uno a otro sistema.

[reborn]

Iniciado por gnzsoloyo

El tema no pasa por duplicidad de datos. Si los datos se duplican (eso sería provocar inconsistencia de datos), lo que tendrías sería un error de normalización.
La primera clave para resolver tu pregunta es determinar si hay un conjunto de 1+N datos que sean opcionales, es decir que puedan o no existir en todos los casos. Si existe un conjunto identificable de datos referidos a un determiando concepto del usuario (direcciones, por ejemplo, teléfonos, familiares), ese subconjunto debe separarse en una tabla dependiente.
Pero en este caso lo que debes definir es si es o no opcional. Si los datos fueran mandatorios (obligatorios), y su relacion fuese 1:1, no tiene ningún sentido separarlos, a excepción de simplicidad estructural y perfomance para las consultas.
En este último caso se refiere a que aún dentro de la misma entidad, tienes N datos que siempre se consultan, y M datos que se consultan esporadicamente y se modifican rara vez. Dada esa situación, por cuestiones de performance podría ser conveniente separarlos.

Una cosa que debes entender es que existen infinitas formas de resolver el diseño de datos para la misma aplicación, y que dos analistas, trabajando con el mismo sistema, con iguales requisitos y para el mismo cliente, pueden plantearte dos diseños completamente distintos e interexcluyentes (uno no incluye al otro e incluso lo contradirce), sin que eso signifique que uno es correcto y el otro no.
Todo depende de cómo se analiza. No existen modos "mejores", no existe en este ámbito "la mejor forma". Lo que sí existen son métodos para llegar a resultados optimizados, pero los resultados varían de uno a otro sistema.

Claro, mi pregunte fue dirigida principalmente a eso, por mas q no lo haya nombrado.

Si son datos opcionales, los agrego en la misma tabla o creo una aparte?

Lo hice de las dos formas, pero la q me resulto mas comoda para trabajar es la de poner los datos en la misma tabla. Cuando digo datos, me refiero a nombre, apellido, email, provincia, ciudad... esos son los datos q quiero agregar.

Todavia no hice un registro de usuarios, solo el super admin puede agregar usuarios, entonces cuando lo agrega solo se inserta el username, el password y el rol de usuario (root, admin, user) y los demas campos estan vacios.
Si el usuario quiere cambiar los datos de su perfil, lo mando a edit_perfil y si no, no se muestra nada.
Si un usuario quiere ingresar al perfil del otro y éste no lo completo o edito, le pondria un mensaje de "El usuario no edito su perfil" o algo similar...

No se si se entiende

[gnzsoloyo]

Personalmente, lo que sean datos como Nombre, Apellido, documento, fecha de nacimiento, o cosas así, las considero parte de la entidad Usuario.
Pero la dirección o el resto de los datos que son extensivos, no. Para mi esos pertenecen al perfil.
En esencia la diferencia radicaría en que los primeros se tratan de datos que administrativamente son relevantes en la relción entre el usuario y el sistema o la empresa. Son importantes para el trato comercial, por ejemplo. Pero los otros tienen más que ver con su interacción social (incluso su ciudad de residencia.
El caso de los teléfonos o los eMails, es siempre convneiente ponerlos como tabla independiente porque no es un dato muy fiable, y además muede tener más de un telefono/e-Mail de contacto, por lo que obligatoriamente requiere una tabla especial.
de todos modos, son una decisión de diseño.

[reborn]

Iniciado por gnzsoloyo

Personalmente, lo que sean datos como Nombre, Apellido, documento, fecha de nacimiento, o cosas así, las considero parte de la entidad Usuario.
Pero la dirección o el resto de los datos que son extensivos, no. Para mi esos pertenecen al perfil.
En esencia la diferencia radicaría en que los primeros se tratan de datos que administrativamente son relevantes en la relción entre el usuario y el sistema o la empresa. Son importantes para el trato comercial, por ejemplo. Pero los otros tienen más que ver con su interacción social (incluso su ciudad de residencia.
El caso de los teléfonos o los eMails, es siempre convneiente ponerlos como tabla independiente porque no es un dato muy fiable, y además muede tener más de un telefono/e-Mail de contacto, por lo que obligatoriamente requiere una tabla especial.
de todos modos, son una decisión de diseño.

Buenisimo, gracias por la explicacion. Sos muy claro.

Es verdad, todo depende de la decision del diseño y como se quieren manejar los datos.

En mi ejemplo es algo sencillo pero es aplicable de todas formas.

[alexperaza]

una sola tabla esta muy bien simplemente valida que no hayan dos iguales ya sea en el nombre o el email y todo bien..