Strutturazione del database per funzionalità "attività" e "seguenti" multioggetto

Hai scritto che non sei limitato ai database relazionali. Potresti prendere in considerazione l'utilizzo di un database grafico, come neo4j . I database grafici sono particolarmente adatti per situazioni come la tua in cui le relazioni sono più importanti, ad esempio, delle medie e delle somme.

Puoi trovare introduzione qui e < a href="https://github.com/thobe/social-network-workshop"> esempio di lavoro qui .

Una struttura più complessa, ma più efficiente che è possibile utilizzare è Graphity .

È difficile da dire senza sapere molto di più, ma sembra che tu voglia qualcosa di molto generico. Forse qualcosa del genere potrebbe aiutare:

activity
--------
  activity_id  - the ID of the activity
  participating_object_id - ID of a participating object
  activity_type_id - ID of the Type of activity
  activity_datetime - When this activity occurred
  data - context data of the activity

Questo ti permetterebbe di avere cose come:

activity_id | participating_object_id | activity_type_id | date  | data
------------+-------------------------+------------------+-------+-----
1           | 2                       | 3                | ...   | this is a post
1           | 84                      | 3                | ...   | [email protected]

Questo descrive un'istanza di attività (ID # 1): un utente (oggetto # 84, dati di contesto "[email protected]") ha creato un post su un forum (tipo di attività 3) il cui ID oggetto è 2 e il la pubblicazione conteneva il testo "questo è un post".

Probabilmente dovrai espanderlo come richiesto dalla tua situazione.

... in realtà, ora che ci penso, la colonna data non è probabilmente necessaria, dal momento che puoi ottenere tutti i dati che desideri dalla tua tabella di base object (qualunque sia l'aspetto) interrogandoli usando i valori in participating_object_id .

Una possibilità è usare "eredità", esp. se gli oggetti a cui fai riferimento hanno campi comuni. Lo schema ha questo aspetto:

followables
    followable_id      primary key
    -- common fields

users
    user_id            primary key references followables(followable_id)
    -- user specific fields

pages
    page_id            primary key references followables(followable_id)
    -- page specific fields

...

random_entities
    ...
    followed_id        references followables(followable_id)

Ciò significa che entrambi pages e users "sono" followables , hanno followables "attributi e possono essere referenziati allo stesso modo.

Gli ORM spesso creano schemi come questo per modellare l'ereditarietà e gestire l'unione per te.

Non preoccuparti dell'inefficienza finché non proverai che si tratta di un problema.

WRT. all'efficienza. Scrivi un semplice script SQL che inserisca le informazioni di test fino al numero di righe che ritieni necessarie. Scrivi le tue domande (ricorda, non vuoi interrogare la tua intera timeline, di solito LIMIT le tue query), controlla la loro velocità di esecuzione, con le cose che hai detto, immagino che la performance sarà soddisfacente. In caso contrario, pubblica le tue query e le uscite di EXPLAIN .

La denormalizzazione diventerà tua amica qui - hai preso in considerazione solo la creazione di una tabella timeline statica che puoi selezionare facilmente?

Vorrei anche prendere in seria considerazione gli archivi di dati non relazionali qui - tendono ad adattarsi bene a questo tipo di problema.

Perché non usare un ORM in grado di costruire lo schema per te attorno alle tue classi? In questo modo puoi allenare i dettagli a un livello più alto di astrazione, lasciare che l'ORM progetta lo schema e quindi rivedere ciò che ha fatto per modificarlo / modificarlo in base alle prestazioni.