I know how to implement things in PHP and MySQL, but now i have a little thinking problem.
There's a forum-website. Every user could post a question (like stackoverflow). So how could it be done that when the user returns (after 2 days, or something) that he sees (a message, or alert...) that he has new posts on his thread?
Do you know what i mean? I can't put that all into a database, I think that's a little bit server-heavy??
Thanks.
If I recall correctly, here's how Simple Machines Forum handles it.
Each user has a record for each thread that they've clicked on. The record stores the highest message ID for that thread at the time it was clicked.
Since message IDs are auto incrementing integers, any new message will have a message ID larger than the previous.
So, when the user views the list of threads, SMF sees if the current highest message ID in the thread is larger than the one stored in the user's thread record. If it's larger, there are new records, and the thread gets a "new messages" icon. Otherwise, the thread gets the "no new messages icon". Also, if there is no thread record, then the user never visited the thread, and it gets a "new messages" icon.
When the user actually clicks on the thread, the thread record is updated with the highest message ID again.
You should store the lastActiveTime of the user on the site. Every time the user visits a thread or a page, update this value for them. The next time they return, do a query for all posts created after the lastActiveTime and present a list of links.
This means you only need to add one field to the user table, and nothing more. This new field contains a simple date from which you can determine the freshness of certain posts.
You can put that all into a database...
Where else would it all go?
Magic Land? ^_^
Just store it all in the database with some sort of time element added to each row.
Related
I have a script that is written in PHP. It uses MySQL database to store records.
Basically, I have team of users that are making random calls to a different business. I want to add list of phone number in a queue "pool table". The system will need to assign the new call to the user. Now If a user is already working on a phone call I don't want another user to start calling the same number. I need a solution to prevent 2 people having the same record assigned to them. So if phone number 000-000-0000 is assigned to the user X the same record will be skipped and the next one in line get assigned to the next available user.
This table will be accessed a lot so I need a good solution that will prevent 2 people from working on the same record and also not cause system issues.
One way I can think of but looking for a better solution is
open transaction
select a call where record status is available
update that call by changing the status from records available to record pending.
commit transaction.
If the use completed the call then updated with a status of completed otherwise make the record available again.
what are other solution available for me?
Thanks
Without a little more information about the workflow, it's hard to know what to suggest, but it sounds like users are interacting with the application somehow while they are taking calls...true??
If so, you must have some way for the user to alert the system they are ready for a call.
ie...
I just started my shift... Deal me a number.
Or...
Submit notes from last call... click submit and Deal me another number.
In this scenario, it seems like it should pretty easy to just let the users "request" the next number. You could probably just insert the users id on that record so it shows in their queue.
i have 2 web pages I have been made with php the first one is for inserting visitors into mysql database the other one is with my manager to let him know which visitor want to met him
my question is how to made the other page play alarm every time i insert someone on my page?
On manager page put timer which would be running for every 1-2 second, if there is new entry in database, either load all entries or just fetch new entries & append it to existing table.
if somebody wants to meet him, then he's going to need their contact information, right? So send him an email with that information...
if($db->query("INSERT INTO users...")) {
mail($email,$subject,$message);
}
otherwise he'll need to keep a browser window open all the time to see some kind of alert or refresh.
I want build a notification system to my website, similar to Facebook. The notifications don't need to be in real time.
This is what I have in mind:
User create an event (upload a new photo, add a new comment, like a photo, or even an administration alert to all users)
Run a cronjob every 5 minutes to add the notifications into the notifications table: id|id_content|type_of_content_enum|affected_user_id|date|seen_bool
The cronjob, will run several functions for each type of notification, for example:
add_photos_notification() // This function will check all photos added in the past 5 minutes, and insert a row in the notification table, for each user following this person. The function will group all photos added into the past 5 minutes, so the follower don't get many notifications for the same type of content. Resulting in a notification like: User X added Y photos in his profile.
add_admin_notification() // This function will check all news added by the administration of the site in the past 5 minutes, and insert a row in the notification table, for each user on the system ...
Is this a correct approach to build a notification system?
Is it possible to miss an event, running a cron every 5 minutes where functions retrieve the past 5 minutes events?
To be safe, do you think an alternative could be checking all events where a field 'notified' is not true? The same function that will grab the events where 'notified' = false, update it to true after adding that notification into the notifications table.
Thanks,
I went with the cronjob route and working good so far. Since our system got so many users to be notified, I found it the most appropriate way to do for two reasons.
I don't need to edit my current scripts code, inserting functions to add notifications for every event I want notify.
Since there gonna be some actions where many users are affected, adding notifications in real time could result in long script delays and time outs.
I built a class called notifications and inside this class, there are functions to add notification for every event I want notify, for example: user_added_a_new_photo(); user_commented_on_a_photo();
For every notification generate, Im adding 1 entry per user to be notified. This is how my notifications db looks like:
id
affected_user_id //user being notified
user_generating_the_notification_id
content_type // enum containing all type of notifications my system has (example: photo, video, comment) ...
content_json // a json containing the notification content. Based on the content type, on the display view file, I call helpers that will format the notification row using the json info.
date // the date the notification was added
seen_on // the date the user saw the notification
clicked_on // if user clicked on the notification, store the date he clicked on it
display // true or false
For this purpose, I added the display field cause for every new notification I create, I check the database if the same user, has another not seen notification, from the same generating user. If this condition is true, I set the old notification to display = false, and group the two new notifications resulting in something like: User X added X new photos in his gallery.
The clicked_on field, stores the date the item was clicked so I can generate reports based on this info if I need to. When displaying the content, if this item is not null, I highlight the notification to mark those not checked yet.
I created a text field to store the notification content in json, cause different notifications has different styles to present the users. For example, a new comment notification, has only texts, but a new photo notification, has a preview thumb.
So far, no issue running it and working for my needs.
The only downside, since the cronjobs can only be run only every 1 minute, the notifications may have 1 minute delay. But since I don't need it in real time, I set the cronjob to run every 5 minutes.
I've been looking into something like this as well and i just found this question on stackoverflow
Building a notification system
Have a look at the answer, the user does shed a fair bit of light on the theory of how to implement this sort of system.
As far as i can see you would need to create a record or object for each notification, if 100 people are subscribe to that event then 100 records will be generated. When a page is loaded your system will find all the notifications that correspond to the user logged in (Maybe by record ID) and then you would notify the user of how many notifications they have.
Now another way of doing this (Note i haven't implemented any of these, they are just ideas) would be to make a notification in a a table, then we'd have a second table that will hold a users ID and a notification ID, a user will be added to this table when they are subscribed to a notification, for example, confirmation of a friend request.
Please note again, these aren't proven methods, they're a result of some of my research of the matter, i'd read the post i gave you before doing anything.
Description:
I am creating comment/reply functionality to a web app that I built. I have a post that I want to link these comments too. To decrease spam and encourage community involvement I want to implement a voting system on each comment/reply.
Problem:
I know how to set up the database and I know how to show upvotes/downvotes. The only thing I don't know what to do is to keep the vote... voted even if the user refreshes the page. I don't want a user to be able to vote up more than once on a single post. Something like the voting on this site, it tracks that you have already voted with a yellow upvote.
What I have thought of:
Place post id in cookie with the user_id appended to it. A simple check of the cookie can stop the user from voting again
Place a unique constraint in table post id... but this is where I get confused. Should I have a separate table just for voted posts? Database schema idea ( I think ) here: https://stackoverflow.com/a/12350981/185672
Keep all the ids in a session array and check against all voted on ids... but that would get huge.
Combination of cookie and database to reduce number of db calls.
In the future there may be 1000s of votes cast by a single user.
edit:
I figured out that storing the results in a database is a must. How can I check for every reply/comment if the user has valid voting privileges without making 1000s of calls?
Resources:
Helped with some further spamming problems, but didn't answer initial question:
https://stackoverflow.com/a/2333085/185672
Old solution that explains how to count votes but not keep the "upvote" checked.
http://www.9lessons.info/2009/08/vote-with-jquery-ajax-and-php.html
Bonus question:
If you guys know of a great script that can allow me to sync up a commenting system ( with votes ) into my already built app?
Also, I tried to find duplicates, but I just can't.
Yeah, just keep a separate table to track user votes. Since you know which user is requesting the page, you can easily join the votes table to determine the current user's eligibility to vote on each post on the page. For each post, if they're eligible, output one version of html, if they're not then output another.
Once the ajax request asks for the php file that does the vote, you can then check once more that that user is eligible to vote - I.e they're changing their vote, or they haven't voted before.
Take yahoo's news stories for example - when you request a page that you've made a comment on, your own comment has disabled voting buttons. With some hacking of the page inside the browser's dev tools, you can enable the buttons. You can even click on them and vote for your own post - though only once.
So, you can see that they got 2/3rds of it right, and output html based on the user's eligibility to vote. They also prevent multiple voting (server-side), they just don't do a server-side check to ensure you're not voting for your own comment.
Stack Overflow on the other hand, always shows the same html - but when you click to vote for your own comment, the server-side code baulks at the idea and the response is basically 'bugger-off! you can't do that' having received a negative result from the server, the javascript on the page pops up the message, rather than updating the vote count.
I suggest you create a "hidden field" in your page that stores information about the upvote/downvote by the user. This is how you would use it:
If the user upvotes/downvotes, the javsvscript on the on the shows the upvote, sets the field to maybe true to indicate the vote status and would also send an AJAX request to the server where the server would record the vote status in the user profile database.
Then whenever the post is re-loaded for a particular user, the server sets the hidden field server-side to true or false, depending on the vote record that is stored in the database. The JS would, on load, check the hidden field and set the vote on the page accordingly (you might need an extra hidden field to indicate whether it is an up or down vote).
I am building a social network site in PHP/MySQL/jQuery. Once a user is logged into my site, I would like to query the DB and get an admin announcement if one exist. This will be a message box that shows on the page to all users but it will have an X to click on it and not show it ever again until the admin post a new announcement message. So if you never click the X and there is announcement messages that exist in the db, it will always show this message box on your page, however if you did cli9ck the X to close the box, then you come back to the page it will not be there, unless there is a new admin message posted.
I know there is several ways of doing this but I am looking for the most efficient way.
One idea I have, if I add an extra mysql field onto the user's table "admin_message" and mark it as 0, then when I post a new admin message it will change the record for every user to 1, if admin message is set to 1 then it shows on user's page. Then when the user clicks the X to hide the box, it will update there user table row and chnage the value back to 0.
Another idea I have is to use cookie's to check if a user has chosen to hide a message, i think this would be faster but maybe not as good, since user can log in with differnt computers and if a new message is shown, they may not see it right away.
So I am just wondering if it is a bad idea to use the extra database field? If I had 1,000,000 users, when I posted a new admin message, then I would need to update 1,000,000 rows to make sure everyone can see the message. Is there a better way? Also once a user logs into my site I will use a session to store the value of them seeing or hiding the message instead of looking at the DB on every page load.
UPDATE
Sorry I think my post might of been a little confusing or not clear on what exactly I meant because most the responses are catered to a message system which this is not anything close to.
Forget the message word please I will try to explain with a different word. Let's say there is 1 admin on the site, that is the only admin who can post a message to users to see. The users will only see 1 message, if there is 2352345234 messages posted over the lifetime of the site, it won't matter, they will only see 1 message, the newest message.
Now some users who log in and see this message "div" on the page might get tired of looking at it, so they will be able to hide it from ever showing again.
It will be as simple as a yes or no for showing this message on there page.
However if I decide I need to post a new admin message for all users to see, then even a user who chose to hide and not show the admin message will still see it again until they choose to never see it again.
Two simple solutions are as follows:
Good: Check the users cookie, if it contains a flag indicating the message was displayed don't display the message, otherwise display it. When the user closes it, update the cookie. Pros: absolutely simple. Cons: The user might see the same message twice depending on if they clear their cookies or log in from another machine.
Better: Store a flag in the database somewhere (you can store it in the admin user table for now, and down the line break it out into another table). When the user logs in, 1) save this flag to the user's cookie or session, 2) update the database, 3) decide whether the message needs to be shown. When the user closes the message, updare the cookie/session and DB. Pros: User never gets shown the message twice. Cons: slightly more involved as you need to maintain the flag in the db.
Implementation details:
For the flag, you could use a message id as suggested already, or more than likely you are already retaining the user's last login timestamp and could use that.
Every user could have a last_message_seen, so you have to query "new" messages (message_id > last_message_seen) for your user. If you [X] close (or timeout), then your javascript can check new messages and so on...
The other idea is to have that last message seen number in the javascript environment, but in that case it will be reseted (recalculated) when you refresh/abandon the page, and if it's not on the DB your user can miss messages inserted between last page load and this refresh.
Or... it can be in the Session, so you don't miss any. When you logon, the number is reseted to some "normal" number, let's say: last message, or message after (now - 1h), or whatever...
You are keeping a login time for the user right? Like a last_login datetime?
So get all messages where date_created >= last_login. Display them, then update the last_login time to now().
I would use idea #1. I wouldn't use a bool-field to check whether the user has read the message, I'd use a datetime-field, with some default value. If field == default, unread. When read, set field NOW().
That way you know aproximately how fast your users read the message.
EDIT:
after your edit, I'd still use the same mechanism. The message needs a field to find out whether or not is read. If the users clicks the X (to close), update the db and mark the message as read.
If the admin posts a new message, this will popup.
You also need a creation-datetime for your messahe, cause if a user did not close the previous message, and the admin posts a new one, only the latest message can be shown.
EDIT2:
In reply to this comment:
Even if a user missed am message, only
the newest should be shown. Maybe I am
misunderstaning but it sounds like you
are saying to basicly mark a message
read 100,000 times is 100,000 users
click the X and I think it should be
more on the user table, show or do not
show message box, not on an individual
basis
something is not locigal in your theory. You want to save the "show/don't show" as a setting, but you want to show the message anyway. How do you know when to overrule the usersetting and when not without remembering whether the system showed the message to the user?
Even if you want to just show it once, you'll need a field in the database (on message-level) to store whether the system showed the message to the user or not.
I'd recommend having a admin_message_queue table. It'll have a message body, a user ID, and a message ID. When you post a new admin message it'll add a record for every admin user to that table. Then when they log in you simply select all admin_message_queue rows where user ID = the logged in user.
To get rid of the message you'd just have the close button trigger an AJAX callback to a method on the server that takes the message ID. That method will delete from admin_message_queue where message ID = the one posted in and user ID = the user ID from the session. That way a user can't delete messages for someone else.
Doing it this way saves you from having to keep around rows of viewed messages. Why toggle a bit to hide it for someone? You'll end up keeping around lots of data that's no longer used.
Updated after question update:
Sorry I thought you were trying to show messages to just admins. You could keep this same logic for displaying the most recent message to all users, too. Simply have a table with a userID, message text. Whenever you post a message it will go through and overwrite the message text for all people that have records still existing (people who haven't hidden the message) and add rows for other people. When they hide the message delete that user's row.