Almacenamiento de amigos en la base de datos para redes sociales

Question

Para almacenar relaciones de amigos en las redes sociales, ¿es mejor tener otra tabla con columnas relationship_id, user1_id, user2_id, time_created, pending o el user_id del amigo confirmado debe ser seralizado/implosionado en una única cadena larga y almacenado junto con el otro los detalles del usuario como user_id, name, dateofbirth, address y limitan a solo como 5000 amigos similares a Facebook?

¿Hay algún método mejor? ¡El primer método creará una gran mesa! El segundo tiene una columna con una cadena muy larga ...

En la página de perfil de cada usuario, todos sus amigos deben recuperarse de la base de datos para mostrar como 30 amigos similares a Facebook, así que creo que el primer método de usar una tabla separada causará una gran cantidad de consultas a la base de datos?

Answer 1

Lo más adecuada manera de hacer esto sería tener la tabla de miembros (obviamente), y una segunda tabla de relaciones de amigo.

Nunca debe alguna vez almacenar claves foráneas en una cadena como esa. ¿Cuál es el punto de? No puede unirse a ellos, ordenarlos, agruparlos o cualquier otra cosa que justifique tener una base de datos relacional en primer lugar.

Si se supone que la tabla de miembros se ve así:

MemberID int Primary Key 
Name varchar(100) Not null 
--etc 

A continuación, la tabla de amistad debe tener este aspecto:

Member1ID int Foreign Key -> Member.MemberID 
Member2ID int Foreign Key -> Member.MemberID 
Created datetime Not Null 
--etc 

A continuación, puede unirse a las mesas para tirar de una lista de amigos

SELECT m.* 
FROM Member m 
RIGHT JOIN Friendship f ON f.Member2ID = m.MemberID 
WHERE f.MemberID = @MemberID 

(Esta es específicamente la sintaxis de SQL Server, pero creo que es bonita cerca de MySQL. El @MemberID es un parámetro)

Esto siempre va a ser más rápido que dividir una cadena y realizar 30 consultas SQL adicionales para extraer los datos relevantes.

Answer 2

La tabla separada como en el método 1. método 2 es malo porque tendría que deserializarlo cada vez y no podrá hacer UNIONES en él; además, las ACTUALIZACIONES serán una pesadilla si un usuario cambia su nombre, correo electrónico u otras propiedades.

Asegúrese de que la tabla sea enorme, pero puede indexarla en Member11_id, establecer la clave externa en su tabla de usuarios y tener filas estáticas e incluso limitar la cantidad de amigos que un solo usuario puede tener. Creo que no será un problema con mysql si lo haces bien; incluso si alcanzas algunos millones de filas en tu tabla de relaciones.