Optymalny pomysł na pobieranie listy postów z wieloma wariantami

Witam. Jak sensownie i w miarę optymalnie zrealizować pobieranie z bazy MySQL, dla danego użytkownika, listy postów o poniższych wariantach:

• posty które użytkownik sam stworzył
• posty które stworzyli jego znajomi
• posty które użytkownik skomentował
• posty które skomentowali jego znajomi
• posty które polubili jego znajomi ?

To powinno być pobrane razem (w jednym zapytaniu), bo ta lista ma wyświetlać się na "tablicy" użytkownika (jak na Facebooku).

Mi przychodzi do głowy tylko jeden pomysł - przy każdej akcji (dodanie komentarza, polubienie postu, stworzenie postu) wykonanej przez użytkownika, zapisywać do jakiejś tabeli (np. "posts_relationships") informację o wykonaniu jakiejś akcji, przez użytkownika X, na poście Y (tylko raz byłaby ta informacja zapisywana, czyli w bazie dać unikalny klucz na pola: USER_ID, POST_ID, ACTION [bo po co zapisywać wiele razy to, skoro wystarczy jeden raz]). Jakimś workerem (np. w NodeJS) pobierać z tej tabeli "posts_relationships" jeszcze nieobsłużone rekordy, pobierać listę znajomych dla USER_ID i w kolejnej tabeli (np. "posts_displays_for") zapisywać dla każdego znajomego osobny rekord (100 znajomych = insert 100 rekordów) [pola: POST_ID, USER_ID, też unikalny klucz dać dla tych obu pól], i przy pobieraniu postów sprawdzałbym tylko czy dany użytkownik jest autorem postu lub czy w tej tabeli "posts_displays_for" istnieje rekord dla jego ID i dla ID postu.
Dobra droga?

Obawiam się tylko ilości rekordów w tej tabeli "posts_displays_for" bo zakładając, że średnio użytkownik będzie miał 50 znajomych, to na dodanych 1.000 postów, w tabeli będzie wygenerowanych 50.000 rekordów. A przy średnio 100 znajomych, na dodanych 10.000 postów będzie wygenerowanych 1.000.000 rekordów. Wydaje się niedużo, a i dodatkowe opcje, tj. "ukryj ten post na mojej tablicy" będzie bardzo łatwe do zaimplementowania przy takim rozwiązaniu :)

Jakieś inne, ciekawsze, lepsze rozwiązanie ktoś podrzuci?

A co w przypadku, kiedy usunie znajomego?
A co w przypadku, kiedy doda znajomego?
Chodzi mi o "stare" posty/komentarze.
Ja bym się ograniczył do jednej tabeli a listę znajomych pobierał na bieżąco.

Jak byś to zrobił na jednej tabeli i z listą pobieranych na bieżąco? Bo ja nie widzę tego obecnie :D

Zrobić na jednej tabeli się da, ale takie zapytanie będzie się 5 minut wykonywać ;)

jedna tabela czyli pierwsza z Twojego pomysłu, listę znajomych musisz gdzieś mieć. Robisz na nich joina i masz drugą tabelę. Zaletą jest to, że jak Ci się zmienią znajomi to nie musisz aktualizować tabeli. Nie wiem, czego tu nie rozumieć.

Dobra droga, dokładnie tą samą idea wykorzystuje twitter do propagacji postów jeśli liczba subskrybentów jest mniejsza od iluś tam tysięcy dla danego konta, powiedzmy < 500k. Inaczej są obsługiwane konta które mają bardzo dużo subskrybentów, wtedy wiadomości nie są kopiowane do skrzynek odbiorczych (odbiorców), tylko bezpośrednio pobierane z tych kont (autorów).

Ja myślę, że problem jest gdzie indziej. Wszystko zależy od tego, co chcemy widzieć. Np. publikuję posta publicznego, mam 20 znajomych.
5 znajomych zalajkowało posta, 30 nieznajomych rownież. Jak na razie sprawa prosta. Z tych 30, dziesięciu dodało mnie jako znajomego. I teraz co? Post lubi 5 moich znajomych, czy 15? "Lubi" 15, ale "zalajkowało" 5.
Tak samo z postami. Tych 10 nieznajomych (wcześniej) dało ileś tam postów, ale wtedy nie byli moimi znajomymi, więc uwzględniać ich w statystykach, czy nie.
I w drugą stronę. Ktoś się z tej 5 znajomych obraził na mnie i zbanował mnie, albo usunął ze znajomych. Jak się to ma do statystyk?