Just a question about what the best way is to send a message to a group (Like whatsapp group messaging).
I save the members per group into a separate database table and once a user sends a message to the group it retrieves the users from this table. I'm a bit stuck on part two:
As I see it there would be three methods.
Insert the message into a database for the entire group. Send the message back to the different users based on groups they are member of.
Insert the message in the database per user of the group. So loop the members and insert for every member. This has the advantage over the first method that downloaded, read and deleted status can be tracked.
Create a table for messages and one for the message-recipient link. But I'm not really sure how a would query in the most optimum way as to retrieve all the data (downloaded, read, etc) for a group of users. Is that possible in a single query?
Would anyone know what the best method would be? I can imagine that method 2 will fill up a database pretty fast, but method 1 doesn't have the ability of tracking status for a message.
At the moment I am using method 1, but I run into the problem that when a user deletes a message. It would still be returned on other devices because there would be no easy way of setting a certain deleted flag for group messages.
Does anyone know how apps like telegram, whatsapp and so on do this? And would method 2 give problems later on when millions of messages are sent?
Regards,
Ron
I would seperate it like this.
Messages
id, message, owner_id, deleted
Groups
id, name
Message_Group
message_id, group_id
User_Group
user_id, group_id
Then you can don't need to add a message to all users in that group. When you insert a new message you first inserts it into Messages, catch the id and inserts it into Message_Group with the message id and group id. To get the messages of a group just join Message_Group and Messages and you are pretty much done. Of course you also needs to join the user table to catch who wrote that messages.
Related
Just like facebook, I have a website which shows lots of notifications from other users.
What I'm doing now is saving notifications of others if they are related to me with my user I'd and the actual user id of that notification in a table called notifications.
And when I login to dashboard I'm fetching all, for each notification I need to display user name so I'm making a query with each notification for the user using the id saved.
Its not efficient and a slow process when I get more notifications on dashboard.
I'm sure there is another tricky way..if I log into facebook it manages very quickly.
Any one had this situation? I'm sire every developer crossed this state, please help me if you have found any better ideas in solving this. So we query once for the associate user and bring the data in a single query.
For better performance you could retrieve the username by using a JOIN in your query when retrieving the notifications for a specific user e.g.
SELECT `message`, `username`
FROM `notifications`
INNER JOIN `users` ON `notifications`.`from_user` = `users`.`id`
I am creating a social website.I have an alert option which needs to show the friend requests and unread messages together based on the time it arrives in various div's .Actually I am lack of logic about how to display results from two tables.Kindly help me.
My tables are:
1)sk_friends=>[friendship_id, from_user_id, to_user_id, status,date]
status contains accepted or pending as values.
2)sk_messages=>[msg_id, from_user_id, to_user_id,text, date, status]
SELECT * FROM sk_friends JOIN sk_message ON sk_friends.from_user_id = sk_message.from_user_id
this will be the basic query for retrieving records from two tables..
try this.. but not sure how much will help you
If you're trying to pull both pending friend requests and messages at the same time, you'll probably want to consider adding a more generic "notifications" style table, or run them as separate queries.
So you could go for a table along the lines of:
sk_notifications => [id, date, type, from_user, to_user, status]
Which would contain both types of events (new messages and new friend requests) - your code would then be responsible for providing the different actions based on the notification type.
for friend request see the query below
select * from sk_friends where (logged_in_user_id in from_user_id or logged_in_user_id in to_user_id) and status='pending';
and for message unread
select * from sk_messages where to_user_id=logged_in_user_id;
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.
I'm looking at creating a user messaging system (similar to Facebook).
What I want to know is essentially what should the table structure look like? The requirements I have are as follows:
Messages are exchanged between users - a sender can select multiple users to send a message to.
Messages are displayed in a thread-style layout, as a 1-1 conversation. i.e. each recipient's reply will appear in it's own thread.
Individual messages cannot be deleted, however a thread can be deleted. Deleting a thread doesn't delete any messages, it just removes that thread from the user's inbox. However the other user can still access the thread if he/she hasn't deleted it from his/her inbox.
Here is what I have at the moment:
Table messages
==============
id (PK)
user_id (from)
subject
body
sent_at
Table message_recipients
========================
message_id (PK)
user_id (PK)
read_status
EDIT: What about the following:
Table messages
==============
id (PK)
thread_id
user_id (from)
body
sent_at
Table threads
=============
id (PK)
user_id (from)
subject
Table thread_recipients
=======================
thread_id (PK)
user_id (PK)
read_status
sender_deleted
recipient_deleted
I would suggest having the following at least:
Users, Threads, Messages
All messages would have a thread
foreign key: thread_id
All threads would have at least one message and at least one recipient (as well as sender)
foreign key: to_user_id, from_user_id, message_id
From there you could simply assign a couple flags to your thread (to_user_deleted, from_user_deleted) that would be updated accordingly.
There a lot more things to consider of course, such what kinds of things you want to account for. For example:
Do you want to display the current message as opposed to the starting message?
Do you want to allow users to mark individual messages as read, or just threads?
You need to take all of these into account while designing your database.
Why not use something like Jabber (example: OpenFire or Web Client)
If you need PHP to interact with it you could use something like:
http://code.google.com/p/xmpphp/ or http://code.google.com/p/jaxl/
#Angelo R. Would like to know why we require the Thread Table? This isn't any discussion board. If you want to retrieve the whole thread/conversation of messages you can simply query by source AND recipient ID.
Plus, if you use Thread, nothing bad. But what in this situation
If new message - new thread_id (automatically created), If replied to existing conversation, you have the thread_id, but what if you are creating a new message (say like facebook popup), you don't know whether there was any previous conversation or if thread_id is available or not unless you execute a special query to it.
This was my thought. Tell me if I might be wrong somewhere.
Now i am working on a social network website and i already built the friends table for this website but i need some suggestion before i moved forward.
I have a user table where user_id is the primary field.
So for friends i made a friends table with fields like
friend1,friend2,is_active
what i do actually when user1 send a friend request to user2 then at that moment i insert the two rows into the friends table like
1- friend1->user1,friend2->user2,inactive
2- friend1->user2,friend2->user1,inactive
So when somebody accept the friend request at that moment i made the both rows as active.
I made this two entries as i want whenever one user block another then easily made that corresponding row belongs to that user will be inactive.
And if a user remove the user then at that time i delete the both entries.
So please i need some suggestion regarding this please help me out to solve this asap.
I need to know is there any other way which will be more optimized than this and giving proper result.
I think that
Friends_table
with
User_id1, User_id2 and Rleationship_id
is easier, index on both first and second column.
relationship id will be 1 - id1 request, 2- id2 request, 3 - friends, 4- id1 blocked, 5 - id2 blocked...
just an idea.