like system

[doddsey_65]

i am trying to add a like system to my forum similar to facebook where it shows how many people like a post.

 

this is my code so far:

 

$like_list = "";
            
            $likes = explode("|", $post_info['post_likes']);
            $amount_likes = count($likes);
            $ac_likes = ($amount_likes / 2);
            $slice = array_slice($likes, 0, 4, true);
            $remain = array_slice($likes, 4, $ac_likes, true);
            $remain_num = count($remain);
            
            if ($ac_likes >= 4)
            {
                for($i=0; $i<$ac_likes; $i+=2)
                {
                    $like_list .= $likes[$i].", ";
                }
                $like_list .= " and $remain_num others like this";
            }
            elseif ($amount_likes == 1    )
            {
                $like_list .= "0 people like this";
            }
            elseif ($ac_likes == 1)
            {
                $like_list = implode(", ", $likes);
                $like_list .= " likes this";
            }
            else
            {
                $like_list = implode(", ", $likes);
                $like_list .= " like this";
            }

 

$post_info['post_likes'] contains data like:

 

user1|123456789|user2|123456789

 

where the number is the timestamp.

 

unfortunatly $like_list prints the username and the timestamp when i would like it to only display the username. This means

printing every 2nd element in the array starting from 0. I have seen this done with for loops but i am not using one therefore i am stuck. Any ideas? and is this the best database setup for likes? the post_likes column is added on to the end of the post table.

[btherl]

A better setup would be a table with username (or userid) as one column, and post id as the other column.  When a user likes a post, you add a row to that table.  If they unlike it, you delete the row.  Then to find who likes a post, you join the post table with the post_like table.

[doddsey_65]

i had thought of that and it would be alot simpler. But what happens if there are housands of people liking thousands of posts. That table would get preety big.

[trq]

i had thought of that and it would be alot simpler. But what happens if there are housands of people liking thousands of posts. That table would get preety big.

 

And? Databases are designed to store data. They especially like it when you use good design practices storing that data.

[btherl]

There's a few approaches to deal with performance issues once you have a lot of data.  You can partition the table, which means storing the data in several different tables according to a rule, such as "If (post id mod 4) == 0, store in table 1.  If 1, store in table 2.  If 2, store in table 3.  If 3, store in table 4".  Then you can look up any post in a table that's 1/4 the size of the original table.

 

You can also cache data in memory, eg using memcache.  Memcache has the advantage that you can have any number of servers load balancing and all accessing the same cached data.

 

Some combination of caching and partitioning should be enough.  The trick is caching the right things and partitioning on the right values.