Solicito opinion

[zeus_bsas]

Solo me gustaria saber como se suelen manejar aquellas personas que hay programado sitios donde el usuario, ademas de guardar su info personal, tiene muchas opciones de configuracion para setear.
Que suelen hacer Uds? Usan la misma tabla de datos personales para poners esos tantos campos de configuracion, o intentan separar esto y ponerlo en otra aparte?
Que es lo mas aconsejable? Hay pautas respecto de esto que hagan que una aplicacion sea considerada como mejor fabricada?

Muchas gracias.

[Por favor Cluster, no me muevas el post, me gustaria saber las opiniones de los usuarios que frecuentan este foro porque me gusta el nivel, please, gracias]

[drcyber]

Hombre... normalmente deberías insertar los parámetros de configuración en la tabla de datos personales. Asi tendrías todo más organizado.

Esa es mi opinión... espero que te sea de ayuda. Saludos.

[zeus_bsas]

drcyber, gracias por tu opinion, es eso justamente lo que busco, opiniones.
Lo que pasa es que quiero armar el sistema pero BIEN armado, y queria saber cual era la practica mas recomendable. A veces tambien pienso como vos, y otras pienso que si se trata de organizacion seria al contrario, deberian ir en tablas diferentes por el tipo de datos que son.

En fin, espero escuchar algunas opiniones mas para ver por lo menos que acostumbran hacer ustedes.
Gracias.

[Webstudio]

Hola Zeus...
TE cuento como lo hice yo ? Hace un tiempo, cuando estabamos programando ZonaPHP, hice una clase genérica de Manejo de usuarios ( que nunca lanzamos, y aún me lamento ) que justamente lo que hacia era abstraer por un lado el manejo de usuarios ( login, password, fechas de registro, ult. login, cant. de accesos, etc ) en una tabla y todo lo que sea Datos separados, por otra.

O sea, tener una tabla que sea solamente con los datos de autenticación del usuario y por otro lado, una tabla con los datos particulares que le incumben a la aplicación ( pensá que no todas las aplicaciones requieren los mismos datos de tus usuarios ). Algunas aplicaciones necesitarán nombre, teléfono, dirección, etc, y otras necesitarán otros tipos de datos, como departamento comercial, referente, etc. Todo depende de la "naturaleza" de la aplicación que estés utilizando.

Aparte, la separación en varias tablas se hace casi natural en este tipo de aplicaciones que utilizan bases de datos, por el hecho de que muchas veces, si la aplicación cambia y requiere que se agreguen nuevos datos para un usuario, entonces que vas a hacer? Modificar la tabla de usuarios y agregar los campos que faltan ? No! Eso es jugar con fuego ( yo se lo que te digo, rompí muchas cosas MUY feo haciendo eso ).

Lo mejor, es tener separados los datos de un usaurio en grupos de tablas en una estructura lógica, y relacionar los datos con un usuario mediante un Foreign Key como el ID del usuario. Por ejemplo, y tomando como ejemplo un Foro, en una tabla tendrias todos los datos de login de un usuario, en otra tabla todos los datos personales de un usuario, en otra tabla podrías tener todos los posts "favoritos" de los usuarios, etc. Ves que de otra manera, meter toda esa info en 1 sola tabla seria, no ya inadecuado, sinó que casi imposible?

Bueno, eso es lo que opino. Cualquier que piense lo contrario, please, me gustaría oir sus consideraciones.

Saludos.

[Cluster]

Bueno .. yo sólo reafirmo la idea de Webestudio ..

Todo separado en tablas y relacionado entre ellas con "claves foráneas" en relación minimo 1->N

Lo típico ...

- tabla "login" (sólo usuario/password .. esta será nuestra tabla "padre")

- tabla "perfil" (datos personales del usuario)
- tabla "preferencias" (de las aplicaciones, incluso "normalizando" más .. cada aplicación de tu sitio debería tener su própia tabla con sus própias preferencias y estas relacionadas con esta tabla o directamente con el usuario que le pertenecen).
- tabla "estadisticas" (para guardar actividad en el sitio; último login .. IP .. etc ..)

En resumen se trata de agrupar en tablas lo que vendría a ser "temáticas" de variables (de tus campos de tu BD) .. que .. si, tal vez los podrías tener en una gigantesca unica tabla de tropecientos campos .. pero a la hora de modificar y trabajar con esa tabla se hace imposible.

Un ejemplo básico de "expansión" del sistema si "normalizas" bien tu modelo de datos sería: La tabla "estadisticas" .. en principio guadars el "último login en el sistema (fecha)" .. pero ahora quieres más contro y quieres tener el registro completo de los login que hace en el sistema .. Ahí (bajo ese modelo) sería tan sencillo como crear una tabla extra tipo "logins" y relacionarla en ese campo por su ID (1 -> N).

Un saludo,

[zeus_bsas]

Cluster, estoy de acuerdo con la mayoria de las cosas que propones, y por ende tambien con lo que dice Webstudio, pero podrias explicarme que sentido tiene tener una tabla solo para nick y contraseña? De verdad no le veo la razon como para no meter estos datos en la tabla que contiene los demas datos como nombre, pais, etc.

[nuevo]

si, la verdad que WebStudio y Cluster tienen toda la razon, si uno no quiere repetir, hay que compartir... con lo cual, si haces eso de los users, con por ejemplo, pulsaciones, version navegador, ip, etc... puedes hacer contadores, con lo cual te da los referers tb si quieres... y eso es mejor dejarlo aparte, ya que serian unas estadisticas, bueno... y eso... yo esq llevo poco tiempo haciendolo asi, y bua, flipo en colores como mola.

[Cluster]

Por ejemplo el hecho de tener una "tabla" para tu usuario/contraseña simplemente es para poder hacer sistemas que la autentificación no sea necesariamente que sea desde una BD Mysql (o la que corresponda) ..

Ejemplo .. Puedes tener tu sistema funcionando para Mysql (o usando una capa de abstracción de BD para más base de datos simultaneamente) pero, .. te podría interesar autentificar a tus usuarios (manteniendo el resto de tablas tuyas: perfil del usuario, preferencias .. etc) en un servidor LDAP por ejemplo o en otros médios como un archivo XML, texto plano .. etc.

Hay ocasiones que se han de compartir "login" iguales entre várias aplicaciones .. ejemplo: un web-mail tuyo en "perl" y tu aplicación en PHP donde, seguramente en tu web-mail tienes la opción de usar un servidor LDAP para gestionar los usuarios/password.

Si separas tus datos de "login" del resto de propiedades de esa cuenta (usuario: perfil, preferencias ..etc), podrías crearte tablas o incluso prescindir de ellas en algunos casos como este mismo del sevidor LDAP donde .. tu programación autentificaría directamente sobre este servidor en lugar de hacer la consulta a tu BD tabla "login". Algún sistema de autentificación podría requerir de algún dato más extra; tal vez un nivel de acceso determinado (pre-fijado para entrar al sistema) .. u otros datos.

La idea principal es "separar" y agrupar los datos que sean comunes bajo un mismo tipo. Por ejemplo, en las propiedades del usuario supuesto, sus datos del "perfil" .. no tienen por qué mezclarse con los datos de acceso al sistema (login) .. entre otras cosas por ejemplo por qué tus aplicaciones podrían no tener un sólo "login" (par: usuario/contraseña) .. Es decir, tu usuario: Pepito talcual .. podría estar relacionado a varias aplicaciones tuyas, cada una con un login diferente si llegase el caso, pero, sus datos personales (perfil) los tendrías sólo en una tabla y los relacionas donde los necesites.

Un saludo,

[zeus_bsas]

Entiendo, muchas gracias...
Bueeeeeenno, a rediseñar la BD. Menos mal que recien empezaba :p