progettazione di database per "follower" e "followings"?

Question

Cari esperti di database/programmatori:

Ho una tabella MySQL con le informazioni degli utenti, come ad esempio

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

Voglio creare una caratteristica come 'seguire' gli altri utenti qualcosa di simile a Twitter. Un utente A può seguire l'utente B, oppure l'utente B può seguire l'utente A, oppure entrambi possono seguirsi l'un l'altro. A tal fine, devo creare 1 tavolo, consente di dire seguaci

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

Ora voglio trovare chi sta seguendo un userA. Mi piacerebbe così: Seleziona * dai follower dove user_id = userA Questo selezionerà userB e userC. Quello è ciò di cui ho bisogno.

Ora voglio trovare, che le persone userA sta seguendo (per esempio in tabella sopra, userA sta seguendo UtenteC e userX. Allora dovrei eseguire qualcosa di simile Select * from seguaci dove follower_id = userA.

mio domanda è che, è questo disegno di database corretto per questo problema (considerando in ridondanza dei database mente e ottimizzazione?) Oppure ci può essere l'approccio migliore di questo? Grazie.

Answer 1

in generale, il disegno è corretto.

Ma , se user_id è univoco nella tabella "users", non è necessario il colonna "id" in "utenti". (Una singola tabella contenente un "id" unico e un "user_id" univoco è piuttosto insolito.) Inoltre, nella tabella "follower" non è necessaria la colonna "id".

La chiave primaria in "follower" deve essere (user_id, follower_id) e assicurarsi che ciascuna di queste colonne abbia una chiave esterna che fa riferimento a "user_id" in "users".

Answer 2

Consiglio generale. Utilizza numeri interi per ID anziché stringhe. C'è una differenza di prestazioni significativa. Quindi rilascia users.user_id e rinomina users.id in users.user_id. In secondo luogo, la tabella dei follower dovrebbe avere indici su user_id e follower_id. Ancora una volta c'è un significativo vantaggio in termini di prestazioni. Mi piace anche l'idea di avere un indice univoco su (user_id, follower_id), che chiama la tua chiave primaria e rilascia la colonna id.

Answer 3

Sì, il tuo design è il solito modo di gestire relazioni molti-a-molti. Cerca "modellazione di database molti-a-molti" e troverai molte risorse che ti forniscono esempi di questo.

Aggiungere chiavi esterne dalla tabella delle relazioni alla tabella utenti.

Se la relazione implica ulteriori informazioni, la inserirai come colonna nella tabella di connessione. Forse, ad esempio, la data in cui un utente ha iniziato a seguirne un altro.

Una chiave surrogata separata nella tabella di connessione, come la colonna ID che è stata aggiunta, può essere utile se si desidera che altre tabelle facciano riferimento alla tabella.

Answer 4

Ecco il mio disegno.

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

ho assunto userId-followerId combiation è unico. Le date possono essere utili.Ad esempio, sto pensando di usarlo se l'utente smette di seguire e ricominciare tra 5 minuti, non genera notifiche. Presumo che l'utente l'abbia fatto per errore. E posso analizzare le seguenti statistiche per data.