Progettazione del DB SQL per supportare i feed degli utenti (in applicazione come Facebook)

Naviga le tue risposte
1

Ho un server di social network con un DB MySql. Voglio mostrare i feed degli utenti come fatto in Facebook. Esempio - UtenteX ora Amico con utenteY, utenteX ha fatto come su postX ecc.

Attualmente ho tabella: C1: UserId C2: LogType (ora amico, ha fatto come ecc.) C3: ObjectId (può essere userId o postId) - imposta in base al tipo di log.

Attualmente per ottenere tutti i registri correlati da mostrare all'utente faccio le seguenti domande: 1. Ottieni tutti gli utenti Amici userIds 2. Esegui una query su tutte le righe che C1 è in userIds (query completata) 3. Scansiona il DB e vedi - se LogType è uguale a DidLike, controlla se OwnerId del post è userId - se sì aggiungilo ai log.

E così via.

Ovvio che non è affatto efficiente.

Sto cercando un modo migliore. Pensavo di aver pensato: Crea una nuova tabella (oltre alla tabella Log) C1: UserId C2: LogId (dalla tabella Log) C3: ID utente di colui che ha eseguito l'azione Quando ha eseguito una query sui log: guarda nella tabella e ottieni Log correlati (da LogId) da LogTable.

Aggiornamento della tabella: ogni volta che l'utente esegue un'azione che dovrebbe essere nel registro: 1. Aggiungere la voce di registro a LogTable. 2. Scansionare il DB e vedere quali utenti sono interessati al Log (Chi sono i miei amici, Chi è il proprietario del post) e aggiungere voci correlate alla nuova tabella. (deve essere fatto in BG). 3. Se l'utente NON CONSENTE un altro utente, cerca nei file tutti i file dove C3 == ID utente NON CONSENTITO ed eliminali.

Qualche opinione? Altri suggerimenti?

    
posta Yoav 27.03.2012 - 13:42
fonte

2 risposte

2

Il tuo problema è che i dati non sono normalizzati, questo è ciò che scrive questa query a Pain.
Può comunque essere fatto, (ti darei l'SQL se comprendessi appieno il tuo modello di dati).

Per normalizzare correttamente i dati, sono necessarie le seguenti tabelle: 

Users
UserFriends - M:M With Users (Needs a timestamp for the action)
Posts - 1:M With Users (Needs a timestamp for the action)
PostsLikes - 1:M With Posts (Needs a timestamp for the action)

Ora so cosa stai pensando Ho creato la tabella LOG per Accelerare, non avere così tanti join! PER evitare questo esattamente ! Beh, in pratica ti sei sparato ai piedi. Perché scrivere query complesse efficienti contro i tuoi dati è praticamente impossibile.

Che il nuovo modello di dati sia Fatto, Se hai bisogno di prestazioni migliori Denormalizza l'intero modello di dati in una tabella gigante chiamata TimeLine, che viene utilizzata per visualizzare la timeline. Questa tabella non sostituisce il tuo modello di dati, ma lo integra. Ogni volta che inserisci un record in una delle altre tabelle, inserisci qui anche un record che registra tale azione. (Inserisci per registrare se l'azione ha effetto su due utenti). Indicizza questa tabella su Userid & TimeStamp . Dovresti sempre essere in grado di ricostruire questa tabella basandoti su altri dati.

Se hai bisogno di una query complessa, consulta le tue tabelle di base.

    
risposta data 27.03.2012 - 15:01
fonte
0

Questo è in gran parte all'interno del regno di "cose non ideali per rdbms"

I database di grafici risolvono problemi come ...

  • L'utente A è amico di User B
  • L'utente A adora il prodotto Z e l'utente B adora anche il prodotto Z
  • L'utente A è amico di un utente B che CONOSCE l'utente C

link

    
risposta data 31.03.2012 - 11:57
fonte

Leggi altre domande sui tag

Ottimizzare i programmi identificando e prendendo scorciatoie di valutazione (calcolo) Copyrights riguardanti frammenti di codice e quantità maggiori di codice [chiuso]