diseño de base de datos para 'seguidores' y 'seguidores'?

Question

Estimados expertos de bases de datos/programadores:

que tienen una tabla de MySQL con la información de los usuarios, tales como

id  user_id   name etc. 
1  userA    
2  userB 
3  userC 
..  .. 
..  .. 

que quieren crear una función como 'seguir' a otros usuarios algo así como twitter. Un usuario A puede seguir al usuario B, o el usuario B puede seguir al usuario A, o ambos pueden seguir el uno al otro. Para ello, debería crear la tabla 1, digamos que los seguidores

id  user_id  follower_id 
1   userA  userB 
2   userC  userA 
3   userA  userC 
4   userB  userC 
5   userX  userA 

Ahora me quieren encontrar que está siguiendo una userA. Me gustaría algo así como: Seleccione * de seguidores donde user_id = userA Esto seleccionará userB y userC. Eso es lo que necesito.

Ahora quiero conocer, que las personas userA está siguiendo (por ejemplo en la tabla anterior, userA está siguiendo UserC y usuarioX. Entonces debería funcionar algo así como Seleccionar * de seguidores en follower_id = userA.

Mi cuestión es que, es este diseño de base de datos correcta para este problema (teniendo en cuenta la redundancia base de datos de la mente y la optimización?) o puede haber un mejor enfoque que esto? Gracias.

Answer 1

en general, su diseño es correcto.

Pero , si user_id es único en la tabla "usuarios", no necesita el columna "id" en "usuarios". (Una única tabla que contiene un "id" único y es un "user_id" único inusual). Tampoco necesita la columna "id" en la tabla "followers".

La clave principal en "seguidores" debe ser (user_id, follower_id) y asegúrese de que cada una de esas columnas tenga una clave foránea que haga referencia a "user_id" en "users".

Answer 2

Consejo general. Use enteros para identificadores en lugar de cadenas. Hay una diferencia de rendimiento significativa. Así que suelte users.user_id y cambie el nombre de users.id a users.user_id. En segundo lugar, la tabla de seguidores debe tener índices en user_id y follower_id. De nuevo, hay un beneficio significativo en el rendimiento. También me gusta la idea de tener un índice único en (user_id, follower_id), llamar a esa tu clave principal y soltar tu columna de id.

Answer 3

Sí, su diseño es la forma habitual de tratar con relaciones de muchos a muchos. Busque "modelar una base de datos de muchos a muchos" y encontrará muchos recursos que le darán ejemplos de esto.

Agregue claves externas de su tabla de relaciones a la tabla de usuarios.

Si su relación implica información adicional, la pondría como columna en su tabla de conexiones. Tal vez, por ejemplo, la fecha en que un usuario comenzó a seguir a otro.

Una clave sustituta por separado en la tabla de conexiones, como la columna ID que ha agregado, puede ser útil si desea tener otras tablas que hagan referencia a su tabla.

Answer 4

Aquí está mi diseño.

Id userId(PK) followerId  followedDate   unfollewedDate 
1  123   456   YYYY-MM-DD HH:MI:SS YYYY-MM-DD HH:MI:SS 
... ...   ...   ...     ... 

que supone ID de usuario - followerId combiation es único. Las fechas pueden ser útiles.Por ejemplo, estoy pensando en utilizar si el usuario deja de seguir y seguir de nuevo en 5 minutos, no genera notificación. Supongo que el usuario lo hizo por error. Y puedo analizar las siguientes estadísticas por fecha.