I have a user model and friendship model. Now I want make that when one user have accepted a new friend, the others friends of this user could see this last activity of her friend. How is the best form to do it?
Thanks.
I have a user model and friendship model. Now I want make that when one user have accepted a new friend, the others friends of this user could see this last activity of her friend. How is the best form to do it?
Thanks.
asked how to show friends’ recent activity after a friend request is accepted. ’s SQL-based suggestion is fine at small scale, but the critical decision is architectural: either build the activity feed on demand (pull) or precompute it for each user (push). Each has trade-offs so choose based on expected traffic and growth.
Pull (compute-on-read): append events to an activity log and, when a user views their feed, query recent events from that user’s friends and merge them by time. This is simplest to implement, keeps writes cheap, and works well for small-to-medium sites. Important optimizations: index the activity table on actor and timestamp, cache each user’s friend list, restrict the query window (last N days), and paginate/lazy-load results.
Push (fan-out-on-write): when an event happens (friend accepted), push a feed item into every friend’s precomputed feed stored in a fast store or a dedicated DB table. Use a background queue so the user action stays fast. This gives very fast reads at the cost of heavier writes and storage duplication. Practical mitigations: cap per-user feed length, expire old items, batch fan-out, and denormalize only the minimum display fields to avoid joins.
A hybrid approach often works best: start with pull, measure real load, then add selective push for high-activity users or top-N friends. Always enforce privacy checks when delivering events, profile slow queries with EXPLAIN, add indexes where needed, and monitor queue backlogs. This roadmap follows the practical advice mentioned by @RamyMahrous while expanding on ’s SQL idea into scalable patterns and operational steps for production use.
Jump to Post— Member #120589The first part has been covered recently - have you checked this forum??
If you freindship model/table is something as follows:friend_id (int,primary key)
target (int, foreign key on user_id)
requester (int, foreign_key on user_id)
status (tinyint or char stating pending/acccepted/refused)
date_accept (date when accepted)You have a …
The first part has been covered recently - have you checked this forum??
If you freindship model/table is something as follows:
friend_id (int,primary key)
target (int, foreign key on user_id)
requester (int, foreign_key on user_id)
status (tinyint or char stating pending/acccepted/refused)
date_accept (date when accepted)
You have a variety of sql methods, including:
1) nested select statements
2) grouping with inner joins
These can be filtered so that only those within the last week say (calculated from date_accept) are displayed under a new friends section.
Hi, thanks for the reply, I have searched in the forum but I don't get the solution. I have the same model/table, one ask more: If I have a lot of people in the web, and therfore a lot of rows of friends, can do that this process will be very slow? I in the forum of database I did the same question and I get this reply:
Ramy Mahrous:
You merge logic or business of your application and the design of the database, you don't need to modify the design if you correctly did it, rather in application check the new friends list in a friend and show them in say news feed to their friends like Facebook.
After he told me that the best was that I will ask in this forum, and now I do it. Can any tell me how I can do the solution that he tell for do the same that Facebook or what is the best solution?
Thanks.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.