I’m currently working on creating a private messaging system, (PHP/MySQL) in which users can send message to multiple recipients at one time, and those users can then decide to reply.
Here’s what I’m currently working with:
tbl_pm tbl:
id
date_sent
title
content
status ENUM ('unread', 'read') DEFAULT 'unread'
tblpm_info tbl:
id
message_id
sender_id
receiver_id
However, I need some help determining the logic on two things:
1) When a new message is created, should the “id” be auto-increment? If the ‘id’ column is set to auto-increment in both tables, how would I set the “message_id” column in the ‘relation table’?
For example, when a new message is created, my MySQL statement is as follows:
<?php
mysql_query("INSERT INTO `tblpm` (title, content, sender_id, date_sent) VALUES ('$subject', '$message', '$sender', NOW())" );
In the same statement, how would I enter the ‘auto-incremented’ value of tblpm into the tblpm_info “message_id” field?
2) What should my MySQL statement look like when users reply to messages?
Perhaps I am making this more complicated than I need to. Any help is greatly appreciated!
1) Definetely yes, id’s should be auto-autoincremented unless you provide a different means of a primary key which is unique. You get the id of the insert either with
mysql_insert_id()orLAST_INSERT_ID()from mysql directly, so to post some connected info you can do eitheror, but only if you’re absolutely sure no one else writes to the table in the mean time or have control over the transaction, after insert do:
or, without pulling the FK to php, all in one transaction (I also advice to wrap the SQL as a transaction too) with something like:
Depending on your language and mysql libraries, you might not be able to issue the multi-query approach, so you’re better off with using the first approach.
2) This can have so many approaches, depending on if you need to reply to all the recepients too (e.g. conference), reply in a thread/forum-like manner, whether the client-side can store the last retrieved message/id (e.g. in a cookie; also affecting whether you really need the “read” field).
The “private chat” approach is the easiest one, you then are probably better off either storing the message in one table and the from-to relationships into an other (and use JOINs on them), or simply re-populate the message in one table (since storage is cheap nowadays). So, the simplistic model would be one table:
(duplicate the message etc, only the recepient changes)
or
(message inserted once, store the relations and FK for all recepients)
Each client then stores the last message_id he/she received (default to 0), and assume all previous messages already read):
or we just take note of the last input time from the user and query any new messages from then on:
If you need a more conference- or forum-tread-like approach, and need to keep track of who read the message or not, you may need to keep track of all the users involved.
Assuming there won’t be hundred-something people in one “multi-user conference” I’d go with one table for messages and the “comma-separated and wrapped list” trick I use a lot for storing tags.
The secret for recepients/readers field is to populate them comma-separated id list and wrap it in commas again (I’ll dulge into why later).
So you’d have to collect ids of recepients into an array again, e.g. $recepients=array(2,3,5) and modify your insert:
you get table rows like
… sender | recepients
… 1 | ,2, //single user message
… 1 | ,3,5, //multi user message
to select all messages for a user with the id of $user_id=2 you go with
Previously we wrapped the imploded list of recepients, e.g. ‘5,2,3’ becomes ‘,5,2,3,’ and INSTR here tells if ‘,2,’ is contained somewhere as a substring – since seeking for just ‘2’,’,2′ or ‘2,’ could give you false positives on e.g. ‘234,56′,’1**,234′,’9,452,**89′ accordingly – that’s why we had to wrap the list in the first place.
When the user reads/receives his/her message, you append their id to the readers list like:
which results in:
… sender | recepients | readers
… 1 | ,2, | ,2,
… 1 | ,3,5, | ,3,5,2,
Or we now can modify the initial query adding a column “is_read” to state whether the user previously read the message or not:
collect the message-ids from the result and update the “recepients” fields with one go