Seguidor de modelado SQL/Relaciones seguidas para redes sociales

Question

Estoy creando un gráfico social para mi sitio web. Los usuarios crearán relaciones (del formulario seguidor/seguido) donde cada parte puede seguir independientemente a la otra. Mi tabla de usuarios es el siguiente:

Users table 
- UserId (PK, Auto-incrementing integer) 

Pensando en cómo modelar esto, yo he llegado con varias alternativas, tales como:

(a) Una tabla contiene cada acción 'seguir' como una fila separada.

Relationships table 
- FollowerId (FK to Users.UserId) 
- FollowedId (FK to Users.UserId) 

Esto tiene la desventaja de que dado a muchos usuarios, crearía una gran cantidad de filas.

(b) Una tabla contiene la lista de usuarios cada usuario está siguiendo como CSV u otra estructura: (? Y costoso)

Relationships table 
- FollowerId (FK to Users.UserId) 
- FollowingUsers (e.g. 2,488,28,40) 

Esto tiene el inconveniente de que las consultas serán mucho más complicado. También tendría que mantener la orden de los valores de cadena, etc ...

(c) Una relación por fila, donde un usuario puede estar en cualquier 'lado' de la relación:

Relationships table 
- Party1Id (FK to Users.UserId) 
- FollowingParty2 (boolean) 
- Party2Id (FK to Users.UserId) 
- FollowingParty1 (boolean) 

Esto ahorra filas sobre (a), pero las consultas son más complejas porque el usuario puede ser cualquiera de las partes.

(d) La colocación de ambos 'siguiente' y 'seguido de' tan listas como (b)

Relationships table 
- UserId (FK to Users.UserId) 
- FollowingUsers (e.g. 2,488,28,40) 
- FollowedBy (e.g. 2,488,28,40) 

Este parece ser el mejor de los mundos, pero ahora tengo que usar las transacciones para actualizar varias filas .

Asumiendo que estoy buscando escalar a un tamaño grande, aunque soy consciente de que "los problemas de Facebook no son mis problemas", ¿qué opción o qué otra opción se prefiere?

Answer 1

me gustaría ir con la opción A.

1. Cualquier tipo de análisis gráfico social será imposible utilizar otras opciones
2. cumplir cualquier tipo de restricciones relacionales será imposible utilizar otras opciones
3. No hay necesita usar una base de datos relacional si no planea almacenar datos de una manera relacional.

Una opción interesante podría ser considerar modelo de tabla de relaciones: mesa

Relaciones

• RelationshipId
• identificación de usuario (FK Users.UserId)
• RelationType

Ahora puede conectar usuarios.

caso B sigue A:

• añadir RelationshipId1, UserAId, "IsFollowed"
• añadir RelationshipId1, UserBId, "IsFollowing"

caso de que otro usuario inicia siguiente A:

• add RelationshipId1, AnotherUserId, "IsFollowing"

caso de que otro usuario inicia siguiente B:

• añadir RelationshipId2, AnotherUserId, "IsFollowing"

incluso puede eliminar filas innecesarias si lo desea: A comienza después de B:

• add RelationshipId3, UserAId, "IsFollowedAndIsFollowing"
• agregar RelationshipId3, UserBId, "IsFollowedAndIsFollowing"
• eliminar RelationshipId1, UserBId, "IsFollowing"