Question

I’m creating a Facebook-like social-network website.
For my “wall”, I have many different kind of information like status, messages, user like/dislike a page, user has updated his profile, …

I would like to know how to design my DB (wall-related tables) to be the more efficient as possible (in terms of speed) when I’ll fetch the wall items.

Thanks in advance!

EDIT: I have 2 ideas:

1. Have a big table with enough columns to handle all possibilities (user_a, user_a, message, page, is_like, is_dislike, …). It will be fast but will have many ‘NULL’ values and will take much space in the DB
2. Have a ‘wall_item’ table with just three columns (id, user_a, user_b) and a table for each kind of wall items (messages, likes, status, …). It will be normalized but will take much more time because of the number of left join needed to get all information.

Answer 1

I propose you have 2 tables – one for content and the other one for likes/dislikes. Having a lot of null values is not a problem – nulls won’t take up space. Keeping likes/dislikes separately is probably needed, because they happen a lot and they are not content themselves.

If you want your system to be scalable then avoid JOIN-s. It is better to execute 2-3 queries in a row than one big massive query with a lot of JOIN-s. Also if you have a lot of READ operations and not so many WRITEs (compared to number or READs) it is wise to do do additional actions during WRITE.

For example you could have a separate table for wall (containing user id and post id). When somebody makes a new post, id of post is written to table WALL for each friend. So displaying wall is just reading post-ids from table WALL and pulling the content – rather than searching for content from posts of all users during displaying.

And when new people become friends you just copy their id-s of their recent posts to each other walls. Good luck with the project!