Ayuda con Consultas SQL

[RyukInside]

Bueno, primeramente mi tabla:

Usuario|Amigo
--------------
tomy....josepe
yoye....josepe
josepe..tony
juan....tony
tony....joel
joel....josepe
joel....juan
josepe..josepe


En teoría, ésta sería el resultado de almacenar de una red social los lazos de amistad existentes.

Mi duda es por ejemplo, si quiero recuperar a todos los amigos de "josepe" haría estas dos consultas:

select amigo from amigos where usuario='josepe';
select usuario from amigos where amigo='josepe';

Así obtengo dos listas con los amigos de "josepe" aunque se repetiría el dato "josepe" pues es amigo de sí mismo.

Cómo harían ustedes para recuperar todo en una sola consulta?
Otra cosa, si se les ocurre una mejor manera de guardar datos para después saber los amigos de cada quien de favor me la hacen saber! Soy abierto a todo tipo de idea/ocurrencia!
Es para un proyecto sencillo de una mini-red social (Lo que esta de moda).

Saludos!

 

[RyukInside]

Bueno, lo eh resuelto con una union:

select amigo from amigos where id_usuario='josepe' union select usuario from amigos where amigo='josepe';

Igual si alguien tiene algún consejo lo agradeceré

 

[westboys]

podria ser asi

bueno yo creo ke tambien asi poidria de funcional.

select amigo, usuario from amigos where usuario='josepe' or amigo='josepe'

 

[vhluja]

¿Y por qué no normalizas la tabla y creas dos tablas?, una que tenga los usuarios y un id, y otra los amigos, relacionados por el id a la tabla de usuarios.

 

[RyukInside]

bueno yo creo ke tambien asi poidria de funcional.

select amigo, usuario from amigos where usuario='josepe' or amigo='josepe'

De ese modo obtienes una tabla con dos columnas, en mi caso sólo quiero una columna donde vengan todos los amigos de un sólo usuario.

¿Y por qué no normalizas la tabla y creas dos tablas?, una que tenga los usuarios y un id, y otra los amigos, relacionados por el id a la tabla de usuarios.

En mi base de datos tengo una tabla para los Usuarios con un id y en otra tengo las relaciones de los amigos(Así como arriba).
A como entiendo lo que dices es crear una tabla de amigos por cada usuario? Si tengo 1000 usuarios crearía 1000 tablas?

 

[CompuDoc]

Necesitas algun tipo de consulta jerarquica, dado como tienes la tabla, algun dia te van a preguntar dame los amigos, de los amigos, de los amigos de "josepe" y esa consulta no te va a servir.

Aqui viene un ejemplo de Jerarquia, solo que con SQL Server 2008.
http://msdn.microsoft.com/en-us/magazine/cc794278.aspx
Incluso viene muy bien documentado.

 

[Herlange]

En mi base de datos tengo una tabla para los Usuarios con un id y en otra tengo las relaciones de los amigos(Así como arriba).
A como entiendo lo que dices es crear una tabla de amigos por cada usuario? Si tengo 1000 usuarios crearía 1000 tablas?

De hecho, la opción del compañero es la mejor. El problema es que te quieres aventar una base de datos cuando al parecer no tienes ni la menor idea de lo que es un modelo E-R (entidad-relación). Tendrías dos tablas (usuario y amigos) con una relación 1 a muchos o una relación muchos a muchos, dependiendo de las necesidades del problema. Ya de ahí sólo tendrías que unirlas con un JOIN o con un FROM de varias tablas (aguas con la cardinalidad).

Te recomiendo que te leas lo más básico de un manual del modelo E-R y ya de ahí puedes ir diseñando la B.D. según tus necesidades. También chécate lo que son llaves primarias y secundarias en SQL, ya que sin ellas no vas a poder unir las tablas.

Por cierto, si tu tabla con la relación de los amigos son sólo esos dos campos no te va a servir para lo que quieres. ¿Cuál es tu llave primaria (o campo primario)? ¿O acaso es una tabla de paso? De ser así, ¿a qué tablas está ligada? Si pudieras mostrarnos tu modelo sería de gran utilidad para que te podamos orientar.

 

[Salandrews]

De hecho, la opción del compañero es la mejor. El problema es que te quieres aventar una base de datos cuando al parecer no tienes ni la menor idea de lo que es un modelo E-R (entidad-relación). Tendrías dos tablas (usuario y amigos) con una relación 1 a muchos o una relación muchos a muchos, dependiendo de las necesidades del problema. Ya de ahí sólo tendrías que unirlas con un JOIN o con un FROM de varias tablas (aguas con la cardinalidad).

Te recomiendo que te leas lo más básico de un manual del modelo E-R y ya de ahí puedes ir diseñando la B.D. según tus necesidades. También chécate lo que son llaves primarias y secundarias en SQL, ya que sin ellas no vas a poder unir las tablas.

Por cierto, si tu tabla con la relación de los amigos son sólo esos dos campos no te va a servir para lo que quieres. ¿Cuál es tu llave primaria (o campo primario)? ¿O acaso es una tabla de paso? De ser así, ¿a qué tablas está ligada? Si pudieras mostrarnos tu modelo sería de gran utilidad para que te podamos orientar.

Completamente de acuerdo. A como lo tienes en este momento solo te implica una gran redundancia e inconsistencia de datos. De hecho la manera en que lo resolviste no respeta la semántica de tus campos, para este caso solo se debería buscar bajo el campo de amigos los que corresponden al usuario A. Como te dijeron ya los bakunos, normaliza las tablas, y una relación de uno a muchos o muchos a muchos según sea el caso. En primera instancia yo te recomendaría una de uno a muchos, de usuarios a amigos, donde amigos serían solo los ids de otros usuarios.