I have one script where am trying to display in a website block The LATEST ARTICLES VISITED BY THE CURRENT USER.
The user can be anonymous or a member.
The articles are in table like [ id_art, intro, text]
So when the visitor X visit a page, i would like to put in the bloc the visited page.
Create a table on the form:
id, tstamp, art_id (key=[id, tstamp, art_id], index=[id, tstamp])
Whenever a user requests an article, add a row with article ID and timestamp. For the ID you can use the user ID for members or an auto-generated ID (persisted in a (session) cookie).
The list is then generated by extracting the latest N records in the table based on the (user/auto) id. (I.e., the actual list is generated by extracting N article titles and links based on a join on the IDs in the two tables.)
Credit goes to silvo for the following point (see comments):
... you should do some periodic upkeep on your table to make sure you don't keep entries that are too old and irrelevant
(Note: This is a generic solution. Nothing specific for Joomla / technology X / ... .)
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 am working on a social network website project. I have created database and everything.
The posts table has a preference column which stores the preference value according to the likes and comments that a post gets from the users and also the time at which the post is created.
To retrieve posts for a user's home page from the posts table, I am running a query using joins which sorts using preference column .
Now, suppose I retrieve 10 posts for a user to be shown on the posts table and user scrolls down and one more request is made from the user to retrieve next 10 posts to the server.
If in between of those requests few other users creates a new post or preference value of posts in the database changes in the between, and now if I the second request is run on the server, all the posts will be resorted for the second request (i.e. to show next 10 posts) but since the database is updated , this means in the second request there will be many chances that few of earlier 10 posts are retrieved along in the second request.
I want to know how to avoid these duplicate requests.
How facebook or any other social network solves this problem at the backend when their database is dynamic.
I would rather avoid such unreliable way of sorting at all.
As a user, I'd rather quit that service. Frankly, I hate such too smart a service which decides which posts I have to see and which not. And even dynamically ordered on top of that.
Make it ordered by date, by tags of interest, by something sensible, reliable and constant.
In your script store a record of the rows id returned.
For example, using a basic limit and just storing the latest id when the first select is done, and using the page number to determine the limit of records to return.
SELECT id, somefield
FROM SomeTable
WHERE id < $SOMESTOREDVALUE
LIMIT $PAGENUMBERTIMESTEN, 10
or storing the latest id after each page is returned (which you will need to store each time this is run)
SELECT id, somefield
FROM SomeTable
WHERE id < $SOMESTOREDVALUE
LIMIT 0, 10
If you store the time & date when the user first makes a request in a session, you could use that to filter the posts table.
So your SQL for the second page of results would be along the lines of
SELECT <some fields> FROM <sometables>
WHERE DatePosted <= $timefirstseen LIMIT 10, 10
Where $timefirstseen was loaded from the session variable. This will restrict your results to only posts that existed when the users visit started.
You would of course need to include a feature to allow the user to clear the session or do that automatically when they revisit their homepage to make sure they got to see the new posts eventually!
As title, when I have a content list, but not everybody can see them.
For example:
I have group 1 and group 2
I create a post, only the users in group 1 can see it.
I create another post, only the users in group 2 can see it.
User 1 in group 1, User 2 in group 2.
Then, when user 1 looks at the newest content list, he can only see the post 1.
Then, user user 2 looks at the newest content list, he can only see the post 2.
You can see, different account (user) will see different post in his/her post list. Because I store all posts in one table, and I store the group_id in it, when creating the newest post list for a user, I have to search all newest post and check one by one if the user can see it or not, if there are too many posts which he don't have permission, the performance will be very bad.
Also, the group is not static in some cases, such as: my followers, my friends, if so, I still can't store the user id in post table, and have to calculate their relationship to determine he/she can read this post or not. and again, the post can be with multiple-permission groups (my followers and my friends can see it).
How can I improve it?
BTW, why I don't insert the user_id array in post record, because maybe the number of group users is very big, so I can only save group_id in it.
BTW again,
I have one SNS website.
I use mongodb database.
I use php.
When user authorizes, store his group_id in session data. Then you can use that group_id when you generate your menu, make it an extra condition in your database query to get only posts that are allowed to this group to be seen.
If the user is not authorizes, you can use some default group_id value to show only posts, allowed for everyone to view.
For complex conditions like the ones you have I'd recommend using UNION if you had mysql, but looks like you will simply need to do multiple queries. First, separate all possible different conditions on which content groups should be available to a specific user.
For example: if user can only see content from his group, his friends and people he follows, you can simply do 3 requests (get content list of his group, posts of people he follows and posts of his friends) and then combine that data with PHP and output it. Since all the data is the same (as you said - it all is in posts table) you won't need anything fancy here. Just three request and sorting the way you want on php side.
I am building a database in MySQL that will be accessed by PHP scripts. I have a table that is the activity stream. This includes everything that goes on on the website (following of many different things, liking, upvoting etc.). From this activity stream I am going to run an algorithm for each user depending on their activity and display relevant activity. Should I create another table that stores the activity for each user once the algorithm has been run on the activity or should I run the algorithm on the activity table every time the user accesses the site?
UPDATE:(this is what is above except rephrased hopefully in an easier to understand way)
I have a database table called activity. This table creates a new row every time an action is performed by a user on the website.
Every time a user logs in I am going to run an algorithm on the new rows (since the users last login) in the table (activity) that apply to them. For example if the user is following a user who upvoted a post in the activity stream that post will be displayed when the user logs in. I want the ability for the user to be able to access previous content applying to them. Would it be easiest to create another table that saved the rows that have already been run over with the algorithm except attached to individual users names? (a row can apply to multiple different users)
I would start with a single table and appropriate indexes. Using a union statement, you can perform several queries (using different indexes) and then mash all the results together.
As an example, lets assume that you are friends with user 37, 42, and 56, and you are interested in basketball and knitting. And, lets assume you have an index on user_id and an index on subject. This query should be quite performant.
SELECT * FROM activity WHERE user_id IN (37, 42, 56)
UNION DISTINCT
SELECT * FROM activity WHERE subject IN ("basketball", "knitting")
ORDER BY created
LIMIT 50
I would recommend tracking your user specific activities in a separate table and then upon login you could show all user activities that relate to them more easily. ie. So if a user is say big into baseball and hockey you could retrieve that from their recent activity, then got to your everything activities table and grab relevant items from it.
I'm wokring on a simple social network site and I would like to build a simple news update feed. Feed not in the actual sense but you know like those little reports you get on facebook eg when someone posts a picture you get a simple report saying in your main page that - so and so added a picture, or so and so added a comment. Stuff like that one liners.
However I want to build something similar. I was thinking of running a union based query on all my tables but that is INSANELY impractical. Another idea I had was to create a news feed table which would have fields like:
Who - Action - ON WHAT
Where 'WHo' - refers to the user ID of the individual who did something
Action refers to the action ie.. adding a comment
WHAT refers to like if the action was done ON something like a comment passed on an article.
However I'm not so sure if this is a good idea... I want a simple solution - any ideas would be much appreciated.
I think this sort of depends on what sort of actions you are expecting to be performed on your items. I'm no expert, but I think the approach I would take is to keep each action distinct.
Let's assume that you have news items to display in your feed, and users can vote on them (or even just 'Like' them a la Facebook) or add a comment about the item.
I'd likely set up my database as such:
NewsItems
---------
NewsId
UserId (if this is like Facebook where it's someone posting their item)
Body
Timestamp
Votes
-----
VoteId
NewsId
UserId
VoteType (or possibly VoteValue with values +1 and -1 or something)
Timestamp
Comments
--------
CommentId
NewsId
Body
Timestamp
Using this, you can retrieve the last n items that a user posted from the NewsItems table, and as you display each, you can use it's NewsId to determine it's current vote count from the Votes table, and also use NewsId to retrieve a chronological listing of all comments made on the item.
I suppose you could also replace the Body field in NewsItems with two other fields, like NewsType and TypeId. The former tells you which table to use to lookup an action (since you probably don't want picture BLOBs and status update text in the same field/table. The second gives you the key to lookup in that table.
Just my two cents. Hope it helps.
thats a tricky and not so easy thing to do.
I worked for a start up social network and it was something they wanted as well.
I dont think i still have the code laying around but if i recall correctly i went about it something like this
DB:
USERS
id : guid "a unique identifier for this user"
"other user info"
ACTIONS
when : unix_timestamp
who : guid "the user who made the actions guid"
type : set('image','news') "replace with a list of the type of things you want to track"
what : url "not like a web address but the guid of the thing that was made"
FRIENDS
id1 : guid "one of the 'friends' guid's
id2 : guid "the other persons guid
PHOTOS
id : guid "a unique identifier for the image"
url : varchar(255) "where is the image stored (file name directory etc)
who : guid "the user who posted the photos guid"
"other info you want to keep track of"
NEWS (think status update)
id : guid "a unique identifier for this statu update"
who : guid "the guid of the person who posted this"
when : unix_timestamp "timestamp of when it was posted
what : text "the contents"
using the above structure i would have my code make an entry into the ACTIONS table anytime a user posted a photo or a status update. then when their friend logged on it would go through the ACTIONS table pulling out all the actions of anyone it found was friends (via the FRIENDS table)
the TYPE field is used to differentiate what table to use when linking the IDs of the actions. so if the person posted an image when it writes the action to the screen it can set the link up to point to whatever script your using to display images. etc etc
ill see if i can find the code, if i can ill post it (company went under and i retain ownership of the code)
If my explanation isnt clear ill take some more time later to better document the process and code.