Organizzare flusso alla Facebook

[Bukowski]

Ciao a tutti,
so che sto tirando su una questione diabolica, ma siccome sto riorganizzando una community, avevo pensato di fare uno stream alla Facebook, più semplificato ma concettualmente uguale.

Con stream intendo avere gli aggiornamenti di cosa fanno gli utenti nel sito.

Esempio: "Giovanni ha appena inserito una nuova foto nel suo album" o "Peppino è diventato amico di Fabrizio" e varie action nel sito.

Ora, è un'oretta che con foglio e penna sto cercando di organizzare questo flusso, e ho dedotto che il modo migliore è creare una tabella ad hoc in cui scriverò ogni azione di ogni utente:

Quindi, qualcosa tipo:

IDUTENTE | ACTION | DATA |
23 | addphoto | 2011-04-05

Qui il problema sarebbe disegnare una tabella che vada bene per tutte le azioni.
Nel caso sopra va bene per aver aggiunto una foto, ma non una nuova amicizia.


Oppure è meglio fare una mega query JOIN e UNION in cui prendere tutti i dati dalle varie tabelle?

Magari a qualcuno è capitato di dover organizzare qualcosa di simile, quale è la strada migliore da adottare?

[oronze]

di base, nel creare una base di dati mi è sempre stato insegnato che se i dati sono presenti è bene non duplicarli per evitare problemi di ridondanza e inconsistenza

[Bukowski]

Beh, i dati esistono fino ad un certo punto, ma anche esistessero nella loro completezza, è chiaro che tante tabelle hanno grandi differenze tra loro, la gestione quindi di un'unica mega-query sarebbe un pò difficile.

No?


Pensavo che incanalare il flusso in un'unica tabella sarebbe stata la scelta migliore, anche per un discorso di indici e di temporalità.

[oronze]

beh, dato che nessuno meglio di te conosce l'architettura dell'applicativo, se pensi che sia l'idea migliore, la tabella che hai creato tu

IDUTENTE | ACTION | DATA |
23 | addphoto | 2011-04-05

la sdoppierei in due tabelle e aggiungerei un campo dettagli

TABELLA FLUSSO
IDUTENTE | ACTIONID | DATA | DETTAGLI
23 | 1 | 2011-04-05 12:00 | urlphoto
25 | 2 | 2011-04-05 13:00 | nomeamico
23 | 2 | 2011-04-05 15:00 | nomeamico

TABELLA FLUSSO
ACTIONID | DESC
1 | aggiunta di una foto
2 | aggiunto amico

che ne pensi?

[Bukowski]

Non mi convince del tutto.

Prima di tutto eviterei 2 tabelle e quindi una join di meno. Tanto se aggiungo un campo in più nella tabella FLUSSO PRINCIPALE non cambia molto.

Poi lascerei nella suddetta tabella un campo ID AUTOINCREMENT, perchè se dovessi sortare per datetime (che è gioco forza senza indice) la scansione sarebbe fatta su tutta la tabella.

Infine ho problemi con la ricostruzione a video dell'azione.

Facciamo un esempio pratico, con le azioni che potremmo avere.

1 = "Aggiungere una o più foto al proprio album";
2 = "Stringere nuova amicizia";
3 = "Lasciare un commento in un'altra bacheca";
4 = "Scrivere un post";

A video le immagino così, dove le sottolineate sono link:

- Peppino ha aggiunto una nuova foto al suo album.
- Peppino ha stretto amicizia con Bukowski.
- Giovanni ha lasciato un commento nella bacheca di Peppino.
- Giovanni ha scritto un post Organizzare il flusso.

Ragionando ad alta voce

#Tabella FLUSSO

IDAUTO | IDUTENTE | ACTION | DATA | TITLE | LINK
1 | 30 | addphoto | 2011-04-05 15:00 | album | /album.php?id=11234
2 | 30 | friends | 2011-04-05 15:00 | Bukowski | /profilo.php?id=Bukowski
3 | 39 | comment | 2011-04-05 15:00 | Peppino | /bacecha.php?id=Peppino
4 | 39 | newpost | 2011-04-05 15:00 | Organizzare il flusso | /post.php?id=11234

Ammetto che non mi faccia proprio impazzire ma per praticità non mi sembra malvagio.

Ho ancora diversi dubbi circa di come potrò risolvere un "doppione" (ovvero, se Peppino mette 2 foto, dovrò raggruppare il dato in una riga) e altre cose di questo tipo....

Tu che ne pensi?

[Santino83_02]

--per la tabella che dicevi te (la chiamerò users_actions)

id - id_utente - id_azione - data - object (integer)

-- tabella AZIONI (in realtà è opzionale questa tabella, puoi anche sostituire id_azione con un varchar)

id - azione (es: 1- addphoto, 2-kill a friend, 3-destroy school, etc)

--ovviamente le fk sono scontate

quando l'utente fa un'azione, mettiamo aggiunge una foto, puoi fare questo:

- salvi la nuova foto nella tabella apposita

- inserisci un record in users_actions dove id_azione sarà l'azione di aggiungere foto e object sarà l'id della foto o dell'album che contiene la foto (scegli te) che userai poi per i link o eventuali associazioni varie

per stampare a video il flusso poi, a seconda dell'id_azione sai che stringa stampare o meno e le eventuali query da fare per completare l'informazione

[Bukowski]

Mmm ... qualcosa non mi torna.

Nel tuo caso dovessi scrivere nella tabella actions un commento inserito per un determinato articolo (o bacheca, cambia poco), come metto, considerando che oltretutto ho anche un rewrite?

Luca ha lasciato un commento per l'articolo Organizzare il flusso.
(L'articolo è rewrittato ad esempio /articoli/organizzare_il_flusso.html)

La tua tabella non mi sarebbe sufficiente, no?

id - id_utente - id_azione - data - object (integer)
1 | 231 | addcomment | 2011... - ????

[Santino83_02]

allora,

visto che immagino che tutte le tue tabelle (foto/commenti/etc) non estendano una tabella singola, ovviamente non puoi mettere una fk nel campo object e da li risalire al tipo di oggetto...allora che fai, ci metti un'azione UNIVOCA, ad esempio adcomment, e allora sai che in object c'è l'id di un commento e quindi per il rewrite andrai a fare una query nella tabella commenti per prenderti il campo che ti serve

Ora, per estrarre i dati le strade sono due: o sei bravo e allora riesci con un'unica query dall'esterno (che ne so, uan stored procedure ad esempio) a ritrovarti tutti i campi che ti interessano, oppure li estrai con chiamate successive man mano che stampi/prepari il flusso

[Bukowski]

Originariamente inviato da Santino83_02
allora,

visto che immagino che tutte le tue tabelle (foto/commenti/etc) non estendano una tabella singola, ovviamente non puoi mettere una fk nel campo object e da li risalire al tipo di oggetto...allora che fai, ci metti un'azione UNIVOCA, ad esempio adcomment, e allora sai che in object c'è l'id di un commento e quindi per il rewrite andrai a fare una query nella tabella commenti per prenderti il campo che ti serve.

Il che significa fare una query per ogni riga estratta.

Ora, per estrarre i dati le strade sono due: o sei bravo e allora riesci con un'unica query dall'esterno (che ne so, uan stored procedure ad esempio) a ritrovarti tutti i campi che ti interessano, oppure li estrai con chiamate successive man mano che stampi/prepari il flusso

Con un'unica query la vedo difficile visto che l'azione è referente a diverse tabelle, a meno che con qualche join non si riesca nell'impresa....
Nel secondo caso torniamo al punto iniziale, dovrei fare una sotto-query per ogni action, butterei il server dopo 10 minuti mi sa.

[Santino83_02]

Originariamente inviato da Bukowski
Il che significa fare una query per ogni riga estratta.



Con un'unica query la vedo difficile visto che l'azione è referente a diverse tabelle, a meno che con qualche join non si riesca nell'impresa....
Nel secondo caso torniamo al punto iniziale, dovrei fare una sotto-query per ogni action, butterei il server dopo 10 minuti mi sa.

guarda, con postgresql tra SELECT CASE e WITH si potrebbe fare tranquillamente un'unica query...col db che hai te non so... cmq se il flusso sono mille milioni di record ogni volta, si butti il server...se invece fai come facebook dei primi tempi che faceva visualizzare 25 elementi del flusso per volta invece non hai grossi problemi di prestazioni