I want to create a user history function that allows shows users what they done.
ex: commented on an ad, posted an ad, voted on an ad, etc.
How exactly do I do this?
I was thinking about...
in my site, when they log in it stores their user_id ($_SESSION['user_id'])
so I guess whenever an user posts an ad(postad.php),
comments(comment.php), I would just
store in a database table
"userhistory" what they did based on
whenever or not their user_id was
activate.
When they comment, I store the user_id in the comment dbc table, so
I'll also store it in the
"userhistory" table.
And then I would just queries all the rows in the dbc for the user to
show it
Any steps/improvements I can make? :)
Look at the statistics and logging section of media wiki schema. You can implement something similar to this.
http://upload.wikimedia.org/wikipedia/commons/4/41/Mediawiki-database-schema.png
Similarly, what you could do is have mySQL based logging, ie every page hit is logged in the mySQL database, which tracks the IP, userid, datetime and page requested.
Then for the page that you view history, you could have a script like this. This is just pseudo code, so take it at face value.
<?php
$actions = array('comment.php' => 'posted a comment', "postedad.php" => "posted an ad");
$query = mysql_query("SELECT * FROM logHits JOIN users ON users.id = logHits.userid WHERE loghits.userid = $userid");
while ($row = mysql_fetch_array($query)) {
echo $row['username']." ".$actions[$row['pagename']."<br />";
}
?>
Again, this is just pseudo code and you can most certainly improve the concept by it. You could possibly use a combination of printf();/sprintf(); and make it so, for example, "a comment" in the action text hyperlinks to the actual comment.
There are quite a few ways to go about this. This probably isn't the best way.
You could also just do an insert query to a table like userHistory whenever the persons does an action like you specified. This is probably the best way to go about it. You could have that able with fields like id, userid, actiontype, actionid
actiontype would be "comment" or so, and actionid would be the id of the posted entry. Then you could easily map actiontypes to the comment page (passing the actionid) to view the actual posted comment.
Related
I'm currently coding a blog to get experience with php(I've made an MVC-Framework), so I am still new to this.
I have two tables important for this question:
user(id, username, password, registrated)
comments(id, content, post_id, comment_author, date, editedAt, editedBy)
In the comments-table comment_author is yet not linked to the id of the user, because I was unsure how to actually do this.
A user can write as many comments as he likes, but a comment can only have one author.
comment_author has the username in it at the moment, but I know I need the id(if the user gets deleted and someone else would registrate with this username, the comment would be his).
How should I now structure the tables?
1.) comments_author_id in comments-table, id in user as foreign key:
In this case I would have the id of the Comment author in the comments-table, but the user would not know about the comments he has written. If I want to show the recent comments of the user on it's profile, could I get them with an inner-join query then?
2.) make a new table user_comments(id, user_id, comment_id)
In this case user and comments wouldn't know about it's author/comments.
Also I have 'editedBy' in which the username of the last editing user is. Can I somehow link it with the username in the users-table or should I also link it with the id?
I am really lost with this question since I don't know much about databases; So I appreciate every help and advice I can get.
Please also let me know if I need to give any further information or change something for a better understanding.
It make sense that you go with the first option.
As you said comment has only one author so just use a foreignkey to user table.
In the second option you're creating a hole new table for a data that doesn't need a new table so you're storing data's that you don't need. also you have to write in two different tables which is two different operations for adding a comment and it gives you no extra feature that you can use.
Best way is create a new table user_comments(id, user_id, comment_id). And if you want to track every changed/edit the comment or post it's will better if you create another table for that and if user can only edit then i think it's better to editedBy fields not generate. The structure totally upto you what kind of tracking you want to be .
I'm sort of working on a CMS type structure. I've got to the point where mostly everything is in place except for small things that I keep pondering on like this one.
So let us suppose there is a user table and an articles table. Now, ofcourse if someone 'likes' an article, the user's ID will be stored in a column in the article's table. Something like this 11241,12412,12312. (these are random user IDs)
Now lets say that there's a user's profile page as well and I want to iterate through the user's liked posts and display it there.
Now, I've thought up of 2 ways of doing this.
First method being that the article IDs that the user has liked are stored in the user's table in his row and we get it from that but this seems sort of inefficient. Because if the user has liked a lot of articles, then I could run out of space in the column of the database?
Second method would be to go through every article and see if the user's ID exists in the list of likers saved of the article. However this method would be really slow and a really bad practice, IMO.
So what's the best practice for this?
Create a table that has two columns: user_id and article_id. When a user “likes” an article, insert a row into this table. Then when you want to see which articles user #123 has liked, you can just issue a query like this:
SELECT `article_id` FROM `article_user` WHERE `user_id` = '123';
If you need the article data, it’s easy enough to just join on the article_id column:
SELECT `article`.*
FROM `article`
LEFT JOIN `article_user` ON `article`.`id` = `article_user`.`article_id`
WHERE `article_user`.`user_id` = '123';
im making a site thats a news/blog kind of site where people can leave comments to the posts that are made. then logged in users are able to give a comment a thumb up or down. it works fine at the moment i click the thumb and it uses ajax to add the count to the database and update the number and it also stops the person from being able to click the thumb again but if you press f5 to refresh the page you can click the thumb up again. how can i stop this from happening?
adding this to a database is an option i was thinking of but the site needs to be able to handle lots of comments and users there could be thousands of thumbs made to comments since its an easy action to perform the database table would be huge after a short amount of time which would surely slow down page loads since it will be querying a massively long table every time you view a page with comments.
currently i keep count of the thumbs up and down in the comment table so it querys the comments table and will display the numbers. are you suggesting i add a new table that contains userid and a commentid if someone makes a thumb up so i can query that table and if there is a row where userid == the logged in user and commentid == the comment dont allow? if so this is the thought i had on how to do it but as i said above it will lead to a massive table that will surely slow down the loading of the page
One way to go is when you load the comments also load if that user has already casted a vote on each of them, disable the thumb up button if that user already voted.
You shouldnt store the click as a simple counter but store the actual event
Create a seperate table called 'clicklog' or something and add the fields like userid, commentid, IsThumbsUp. Then in your ajax page you can add the thumbs up to this table (IsThumbsUp is a boolean. True for thumbsup and false for thumbs down.
then instead of using something like SELECT comment, thumbsUp, thumbsDown you could use
SELECT id, comment,
(SELECT count(commentid) FROM clicklog WHERE commentID=id AND IsThumbsUp=1) AS thumbsUp,
(SELECT count(commentid) FROM clicklog WHERE commentID=id AND IsThumbsUp=0) AS thumbsDown
FROM comments
And also in your AJAX page you can check if the user has voted before. If he has, dont allow it. Or even better. When he has voted UP, he can change it to vote DOWN (change the IsThumbsUp from 1 to 0) or visa versa.
Just make sure each user only has one connection with commentid and userid.
Also make sure you put an index on the fields in clicklog to get the information quickly. I'd put the primary key on commentid and userid combined and then a seperate index on commentid and IsThumbsUp combined
So I'm a bit lost at this part.
On my site I would like the give the ability for users to like profile pages.
So my logic is this.
I have a database table named user_likes, this contains 3 rows, id, user_id, liked_by.
The actual profile page has a like button on it with a class like.
When the user clicks on it in inserts the data in to the user likes table and changes the button text to unlike and the class to unlike too with ajax.
And this is the part where I'm stuck.
So the profile has a has many relation likes, I can count the likes received, but I'm stuck at that part how to keep the button unliked after page refresh.
Because my logic was this (but its a fail):
onclick the button, data insert with ajax, button change with ajax, grab the liked by id and if that equals to the logged in users id keep the button unliked.
But since it returns a list of array I can't do that.
So I don't want anybody to code it for me, I would just like a hint for this if its not a big request.
I saw that you posted the same question on the FuelPHP forum, so here I will try to give you another solution.
Why your relation needs "id, user_id, liked_by"? I think you can improve you database modifying a little your tabel.
Reading your question I think you have a structure like that:
// USER TABLE
id
username
... something more
If you create a table named "LIKE" you'll have this situation:
// LIKE
id
created_at
modified_at
... something more
So now you can create a many-to-many relation with a table named "users_likes" with:
// USERS_LIKES
profile_id // it wil be related to the user_id, is the user's profile being liked
liker_id // it will be the user_id of the user that likes the profile
So if you want to retrieve the number of the like you'll have all the information in the current user model or in the profile user model.
I would like to make it able for my users to add each other as friends. I just don't know exactly how to do it.
I have a table called "members" where the users have (ofc) and ID,username,pass etc etc. and then I was thinking of creating another table called "friends", where I was planning to have the rows -> username (the friend added) and friend_to (who the friend 'belongs' to).
But; I just don't know - how I should make the "add friend" link, and make it INSERT INTO the table? Can I make an onClick on the link, or what should I do? :-s
Thanks in advance.
Have a table called friends have rows, (id, user_id, friend_id, status, time)
id is the index, user_id is the one requesting friendship, friend_id is the receiver, status is the status of friendship like pending or declined, and time is the timestamp of the time when the request was sent.
Then in a php code check if the users aren't friends then let them add each other as friends. One way you could check was like this
(SELECT COUNT(*) AS total WHERE (`user_id` = ".$_SESSION['user_id']." AND `friend_id` = ".$_GET['friend_id'].") OR (`user_id` = ".$_GET['friend_id']." AND `friend_id` = ".$_SESSION['user_id']."))
the above code will check if they are users, and if they are you would not let them re add each other, if they aren't the user gets a button to add them to friends, where it inserts into a database new row, with user_id being the user sending and friend_id the user's page the sender is submitting the button from
On the backend, you will need separate PHP functionality (easiest way is to simply have a separate PHP page) to handle the result of the "add friend" link. Your table layout seems adequate from what you have describe. The "Add Friend" link will need to send a request back to the add_friend PHP handler which includes ID of the user and the ID of the user they added. And this handler will be where you include the MySQL code for performing the insert, based on the data that is provided to it.
On the front end, you can have the link send them to a new page, or you can use an onclick event to issue an AJAX request and update things behind the scenes without requiring a page reload. That choice is up to you and what fits your design best. The later is more complicated and will require some Javascript and/or jQuery to handle the AJAX parts, but it often results in a more pleasant user experience.