Relacion de amistad

[ccsaiKo]

Hola, tengo una pregunta.


Si quiero guardar las amistades ...
sera necesario tener dos registros de esto? me explico..

Si juan es amigo de pedro
es necesario que pedro sea amigo de juan ?

----TABLA AMISTAD ----

--COD---US1---US2

-- 1 ----pedro---juan
---2----juan----pedro

Gracias.

[gnzsoloyo]

O pones los dos registros, o la consulta se complica muchísimo.

[ccsaiKo]

En que sentido se me puede complicar?

por que . antes tenia una columna de bloqueos en donde podia ver si usuario 1 tenia blokeado a usuario 2 ..

--cod--us1--us2--blocked
--1-----4------6-----1
--2-----6------4-----0

aqui podia ver que un usuario tenia bloqueado a otro y el otro no lo tenia bloqueado.

pero pensandolo .. podia tener una tabla blocked con todos los bloqueos de los usuarios.

entonces.. no le vi mayor funcionalidad.. me podrias dar un ejemplo :)?
muchas gracias.

[AXLAV]

Y bueno, si lo planteas como dos tablas, donde una es USUARIO y otra es BLOQUEO
Te querdarìa una relaciòn m a n, y la resolve creando otra que herede ambas PK de cada tabla y que contenga la fecha y la hora en que es realizo el bloqueo .

[jhsilva]

Iniciado por ccsaiKo

Hola, tengo una pregunta.


Si quiero guardar las amistades ...
sera necesario tener dos registros de esto? me explico..

Si juan es amigo de pedro
es necesario que pedro sea amigo de juan ?

----TABLA AMISTAD ----

--COD---US1---US2

-- 1 ----pedro---juan
---2----juan----pedro

Gracias.

Creo debes preguntarte al menos esto:

1. Cuantos registros pretendo tener en esta tabla.

Si lo ves de un tipo social de algo pequeño no habría problemas que incluyeras ambas tuplas para que sea más objetivo y al consultar sea sencillo el filtro, pero si es una tabla con gran cantidad de registros podrías replantearte si separas en 2 tablas y tendrías la mitad de registros al consultar. Eso lo decides tú.

Al menos como lo veo yo esta bien que lo hagas de la manera que propones, sino tendrías que preguntar todos los amigos donde US1 = ID y US =ID y que no se repitan...

2. Relentizará la consulta el que agregué ambas tuplas por cada situación de amistad

Esto tiene que ver con lo anterior también a la hora de filtrar y traer las amistades vé bien de cuantos registros hablaras. En algunos casos no tiene sentido crear más de una tabla o varios campos si al final la consulta no influye en el tiempo de respuesta significativamente.

Saludos

[AXLAV]

Iniciado por jhsilva

Creo debes preguntarte al menos esto:

1. Cuantos registros pretendo tener en esta tabla.

Si lo ves de un tipo social de algo pequeño no habría problemas que incluyeras ambas tuplas para que sea más objetivo y al consultar sea sencillo el filtro, pero si es una tabla con gran cantidad de registros podrías replantearte si separas en 2 tablas y tendrías la mitad de registros al consultar. Eso lo decides tú.

Al menos como lo veo yo esta bien que lo hagas de la manera que propones, sino tendrías que preguntar todos los amigos donde US1 = ID y US =ID y que no se repitan...

2. Relentizará la consulta el que agregué ambas tuplas por cada situación de amistad

Esto tiene que ver con lo anterior también a la hora de filtrar y traer las amistades vé bien de cuantos registros hablaras. En algunos casos no tiene sentido crear más de una tabla o varios campos si al final la consulta no influye en el tiempo de respuesta significativamente.

Saludos

Pero ademàs de ser màs pràctico, en el caso de que sea una tabla muy conultada, podrìa crear un indice .

[jhsilva]

Iniciado por AXLAV

Pero ademàs de ser màs pràctico, en el caso de que sea una tabla muy conultada, podrìa crear un indice .

Eso también es una buena idea. Se me habia ido . Muchas gracias por recordarlo.

Saludos