Como organizo tabla para visitas?

[martuanez]

Tengo un par de dudas una es respecto a como organizar una tabla para contar las visitas, es una página de modelos, las visitas son a un perfil, por lo que le pondría una clave foranea con el id del usuario en cuestión en un campo y otro campo con las visitas? o con una visita y que me cree nuevas entradas por cada visita?, o sea si actualizo el campo de visitas perdería la noción de cuantas visitas tuvo durante x tiempo o en un determinado momento, de la otra manera generaría un montón de entradas(quizás con fechas ) pero me confundo al momento de plantear la consulta....
Que estructura me recomiendan?
que tipo de consulta?
Esas son mis dudas...
Gracias!

[TolaWare]

Asumiendo que tienes estas tablas:

Usuarios:
id_usuario (llave primaria)
....

Perfiles:
id_perfil (llave primaria)
....

Enfoque Nº1

La primera opción es hacer una tabla visitas de manera que cada vez que un usuario visita un perfil, se genere un nuevo registro en esta tabla. La tabla sería así:

Visitas:
id_visita (lave primaria)
id_usuario (llave foránea a la tabla Usuarios)
id_perfil (llave foránea a la tabla Perfiles)
fecha_hora
...

Cada vez que un usuario visita un perfil, se agrega un nuevo registro a esta tabla, guardando el id del usuario que visita el perfil, el id del perfil que visita, y el momento en que lo visita.

El enfoque explicado es el más flexible de todos, ya que te permite recopilar toda clase de información estadística, de quién, cuando y qué visitó. Como vos dijiste, tiene la contra de que cada visita genera un nuevo registro, y si la cantidad de visitas que realiza cada usuario y la cantidad de usuarios son muy grandes, entonces estás en problemas.


Enfoque Nº2:

Una forma de contrarrestar el problema citado anteriormente, es no guardando el momento en que el usuario hace la visita al perfil. Las tabla de visitas quedaría así:

Visitas:
id_visita (lave primaria)
id_usuario (llave foránea a la tabla Usuarios)
id_perfil (llave foránea a la tabla Perfiles)
cantidad
...

De esta manera, cada vez que el usuario visita un perfil, lo único que se modificaría es la cantidad, ya que este campo identifica la cantidad de veces que el usuario visitó el perfil.

De esta manera, sólo se inserta un registro cuando el usuario visita por primera vez el perfil. Las sucesivas visitas del usuario al mismo perfil, sólo incrementarían el campo cantidad.

Otra ventaja de este enfoque es que para consultar cuantas visitas tiene un perfil, deberá escanear muchos menos registros de la tabla, incrementando la performance de tu aplicación.


Enfoque Nº3:

Un tercer enfoque posible, es evitar guardar el usuario que realiza la visita. Es decir que sólo mantendremos un contador de las visitas realizadas al perfil. La tabla sería así:

Visitas:
id_perfil (llave primaria a la tabla Perfil)
cantidad
...

De esta manera, cuando un usuario visita un perfil, sólo se incrementa el campo cantidad. Cómo ya no se especifica que usuario hace la visita, sólo se realiza una inserción cuando el perfil es visitado por primera vez. De esta manera se gana mucho rendimiento a la hora de registrar la visita y a la hora de consultar la cantidad de visitas de un determinado perfil.

Bien, estas soluciones que te he planteado, son sólo las básicas. Podés usar cualquier otra que se te ocurra, o inclusive una combinación de las que nombro.

Saludos y espero haberte ayudado.

[martuanez]

mmmhh... me quedo con la 3! que me gane?..jeje muchas gracias por tu detallada explicación me viene de pelos!
Graciaaasss!!

[TolaWare]

De nada martuanez, me alegra haberte sido de ayuda.

[paloto]

Solo una puntualización... En el Enfoque 3, el campo Cantidad podría ser un campo de la propia tabla de Usuarios, no sería necesario crear la tabla visitas ¿no?

Un saludo

[tute666]

No es necesario.
Es una relacion uno a uno para separar los datos de visitas, es una cuestion de comodidad por un lado, ya que permite separar los updates e inserciones de visitas en otra tabla, sin embargo al hacer una busqueda de perfiles con sus visitas, va a implicar el costo del join entre las tablas perfil y visitas.