I want to create a Facebook like newsfeed for my users that basically does the following
it keeps track of the activities of users and their friends
users can see recent friend activities on their newsfeed
but i am not quite sure how best to implement this in mysql. Like what sort of tables will I need? What is the structure of these tables? What will I store in these tables? How will I keep track of user and friends activities. I want to build an efficient system that will scale up. I prefer working with PHP and Mysql if possible!
I was thinking of having a NEWSFEED table and when a user does something (posts a comment, etc), I add an entry to that table for the user's friends and the user himself that will show up on their newsfeed.
The table structure would be as follows
uid INT
activity ENUM
activity_id INT
So let's say I have a comments table with the following structure:
title VARCHAR(255)
message TEXT
If the user posts to that table and an entry with ID=5 gets created for that user, then the following entry will be added to the NEWSFEED table
uid=3 activity="comment" activity_id=5
that means that to display the newsfeed for each user, I would have to do the following:
SELECT * FROM newsfeed WHERE UID = ....
FOR EVERY ROW:
CHECK activity type (if activity == 'comment')
**QUERY the corresponding table and display the result (so I would query the comments table an display the person's comment)**
I am thinking of deleting entries more than >3 months old to prevent the table from getting too huge. But I don't like that I am doing independent queries to display for each activity type (just as I did above where I queried the COMMENTS table to display the comment whose ID is mentioned in the NEWSFEED table).
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
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';
So I have a question, I'm hoping it isn't too subjective.
I have a blog-style website, so on the homepage articles are loaded alongside the date published, the user that posted it, etc. Basic data like this.
I store it in MySQL like so:
article_id username date content etc.
1 user1 2015-05-14 01:35:14 my content a
2 user2 2015-05-16 02:33:15 my content b
This way, I can display it using one query, where I retrieve the username, date, content, etc.
My question is. I want to allow users the option to change their username. There are two options I see for this.
Either I continue storing data as I do now, and manually update tables like this with user-related data to the new username. Or I store data by a user_id rather than username, and have an extra query for each article loaded to get the associated username from another user table.
Which is the correct approach?
I ask this because I assume there's a recommended practice for this situation? Is it normal to store data by username and update it, or to store by id to avoid having to do this - but at the cost of the overhead when querying data. I'm guessing it's possible to display the username for id-based data in just one query, but that would still take significantly longer?
Depends. Do you see there is a 1:1 relationship with Article:User if yes, then storing in a single table will probably suffice but generally an user will publish multiple articles which will make it a 1:* relationship and in which case you should create a separate table for UserDetailsd and have user_id as FOREIGN KEY in Article table probably.
You should create a users table, store user_id which would be incremental and a user_name. When showing the user name in your app, join to the users table and show the name from that table and it will always be current. This is the best practice if you wish to allow user name changes. Updating all usernames it the articles table is not recommended. This will also allow you to store other user related information such as email, join date, etc... without having to keep all that in the articles table.
Create a seperate table with all user-related information and alter your current table, so only content and article related stuff is included. That's what I'd suggest you
Make a separate table for users something like:
-------------------
user_id | user_name
-------------------
Where user_id should be PK.
And another table, lets say article should look like:
-----------------------------------------------
arcticle_id | date | content | etc. | user_id
-----------------------------------------------
Where article_id could be a PK and user_id would be the FK from users table, making a relationship which could be used in other tables as well.
You can create a table for users, and use a foreign key on field username, specifying the behavior on updates. Is something like this:
alter table posts add constraint fk_post_user foreign key (username) references users (name) on update cascade;
In this way, when you update a row on table users, all user names on table posts will be updated too.
I'm developing a Web app that revolves around the Twitter API. I'm a newbie and this is my first ever attempt at development so be gentle (please).
The problem I'm facing is:
I have a table that contains the twitter user info: UserID(Unique) Name etc..
And another with specific tweets: TweetID(Unique) Text etc..
I want to be able specify if a particular UserID has Retweeted the tweet(using TweetId) already.
I don't care if he has retweeted outside my App, I just want to know if he did using my web app so I don't display it to him twice.
It's kind of conventional to name your columns in small letters(snake_case_ name_of_column).
Are you asking for schema or query?
If schema,
Firstly, create another (one-to-many relationship) table named user_tweets that have columns (id | tweet_id | user_id). The columns are foreign keys to the tweet table and user_id table
For each tweet, you insert the tweet_id and user_id irrespective if it was a re-tweet or not,
For each tweet or re-tweet, you insert a new tweet record in the user_tweets table and when retrieving record to display a users tweets, you select only distinct records from the user_tweets table where the user id is for the user you are looking for, This returns the distinct tweets.
Hope this helps.
In a social networking site we have a scenario like taking news feed of friends against logged in user.
I have a user table, membership table and feed table.
Here membership table is using for friends data.
User table have more than 100K entries and membership take have more than 400K entries.
I have two way to take friends feed...
Either by joining the feed and membership tablle
select * from feed join membership on ... where ....
Or by IN statement like
select * from feed where user_id IN (userids of friends)
Here i am facing a loading issue when making a join statement for a newly registered user having a single friend.
So which is the best method for along robust future run ?