Social Activity Stream

[absolom]

Ciao a tutti,
quello che voglio proporre non è un quesito vero e proprio ma una proposta per ragionare assieme!

La mia necessità sarebbe quella di creare un Social Stream all'interno della mia applicazione. Per intenderci, il Social Stream è la lista delle ultime attività svolte sull'applicazione da utenti a cui sono collegato, proprio come fanno facebook, twitter, G+, e moltissime altre applicazioni, non solo strettamente social.

In fondo per larghe community di utenti, questo è l'unico modo valido per proporre contenuti sempre nuovi sfruttando la co-creazione.

Scrivo qui innanzitutto perchè uso php+MySQL, e perchè penso che per questa problematica si possa partire proprio dal DB e dal Data Model.

Ho tentato qualche strada, ma sono sempre naufragato, se qualcuno è interessato possiamo condividere i ragionamenti e trovare insieme una soluzione accettabile.

[optime]

dove hai trovato l'intoppo?

[absolom]

Leggendo vari articoli e post sull'argomento sono partito dalla rappresentazione di un activity secondo questo schema:
USER_ID -> l’utente che ha generato l’activity
SOURCE_ID -> l’ID dell’oggetto su cui è stata eseguita l’activity
ACTIVITY_CODE -> il tipo di sctivity (ADD_FOTO, ADD_COMMENTS, etc..)
DATA-> la data di creazione dell’activity

Nella mia applicazione gli ID sono univoci solo all'in terno della stessa tabella (ID AUTOINCREMENT), per cui ho pensato di aggiungere il campo SOURCE_TABLE, come di seguito:

USER_ID -> l’utente che ha generato l’activity
SOURCE_ID -> l’ID dell’oggetto su cui è stata eseguita l’activity
SOURCE_TABLE -> la tabella in cui risiede l’oggetto
ACTIVITY_CODE -> il tipo di sctivity (ADD_FOTO, ADD_COMMENTS, etc..)
DATA-> la data di creazione dell’activity

Il problema nasce in fase di SELECT, in quanto ogni activity interessarà oggetti di tipo differente, foto, commenti, profili, e quindi dovrà essere eseguita una JOIN diversa... questo processo partendo da questo modello lo trovo troppo farragginoso

[optime]

dipende da quali info andrai a ripescare dalle tabelle collegate

[absolom]

Il mio problema più che quali informazioni, è la join in se...

Se non ho capito male.... qualcuno parla di denormalizzazione, cioè, credo, aggiungere un ulteriore campo alla tabella activity, in cui viene conservata la struttura del singolo oggetto activity, in base alle informazioni che servono per poi per mostrarlo all'utente, es:

nel nuovo campo METADATA:
{photo_id: 1, photo_name: Getting married}

questo potrebbe aiutarmi?

Posso comunque assumere di andare sempre in join con la tabella utenti, in quanto rappresenta l'unica costante.

[optime]

può aiutare sì e no; dipende da quanta roba va nel nuovo campo metadata (per questo ti chiedevo quali info vuoi recuperare!); se nella nuova colonna metti due dati va bene, se ce ne metti 100 è più il tempo che impieghi a fare il parsing che quello che impiegheresti a fare la join. considera anche una soluzione ibrida: nella colonna in più metti i dati strettamente necessari a fare la ricerca e una prima visualizzazione; terrai tutte le altre info nella tabella apposita. Attenzione che INSERT, UPDATE e DELETE andranno fatti non solo nella tabella collegata ma anche nella principale

[absolom]

ma la join è fattibile? nel senso che il problema che mi pongo è se si possa fare una sola query che recupera lo stream!

questa è la costante (con gli utenti):

SELECT u.id, u.nome
FROM activity a, users u
WHERE u.id = a.user_id

da qui, se l'activity è una ADD_PHOTO, devo andare in JOIN sulle photo, se è una POST_COMMENT ed il commento è stato aggiunto che so... ad un video, devo andare in JOIN sulla tabella dei VIDEO...

questo split non capisco....

[optime]

fa' un esempio di quello che vuoi ottenere

[absolom]

[Foto utente] Nome_Utente "posted a photo" in [LINK]album[/LINK]

"posted photo" potrebbe essere il risultato di un mapping tra il TYPE dell'activity e il relativo VERBO?

[optime]

se tu fai un'unica tabella attività, le info in

[Foto utente] Nome_Utente "posted a photo" in [LINK]album[/LINK]

le ricavi tutte con una un'unica istruzione, tranne "album". Se però elenchi tutte le possibili attività, potresti strutturare la tabella attività (servo assistita da una tabella "tipo attività" aggiungendo qualche semplice colonna addizionale (nell'esempio che hai fatto, la colonna "album")

P.S. poi tutto dipende da *quanti* dati pensi di trattare