News feed database design as in Facebook News feed database design as in Facebook sql sql

News feed database design as in Facebook

Firstly, consider doing a performance prototype to check your hunch that the union would be too expensive. You may be prematurely optimisizing something that is not an issue.

If it is a real issue, consider a table designed purely to hold the event feed data, that must be updated in parallel with the other tables.

E.g. when you create a Note record, also create an event record in the Event table with the date, description, and user involved.

Consider an indexing the Event table based on UserId (or UserId and Date). Also consider clearing old data when it is no longer required.

This isn't a normalised schema, but it may be faster if getting an event feed is a frequent operation.

It's hard to answer this question without a schema, but my hunch is that a UNION involving 10 or more properly indexed tables is nothing:
A typical LAMP application like wordpress or PHPBB runs more than 10 queries per pageview without problems. So don't worry.

UNION = expensive, because the complete result set is subject to a DISTINCT operation.UNION ALL = cheaper, because it is effectively multiple queries for which the results of each are appended together.

It depends on the data volume, or course.

The main driver of efficiency would be the individual queries that are unioned together, but there's no reason why selecting the most recent (say) 10 records from each of 10 tables should take more than a small fraction of a second.