Private Message Database Design - mysql

Alright, so I think I'm pretty close to having what I need, but I'm unsure about a couple of things:
TABLE messages
message_id
message_type
sender_id
timestamp
TABLE message_type
message_type_code (1, 2, 3)
name (global, company, personal)
TABLE message_to_user
message_id
receiver_id
status (read/unread)
Goals:
Be able to send GLOBAL messages to all users.
Send PERSONAL messages between 1 or more users.
Determine if any of these messages have been read or not by the the receiver.
Questions:
Does my schema take care of all that it needs to?
What would a sample SQL query look like to populate someones inbox, bringing in GLOBAL messages as well as PERSONAL messages - I'd like to be able to determine which is which for the UI.
And please feel free to add to my schema if you feel it would benefit.

Schema looks like it will work. Should probably have a Created date too. There's no way to know if you've read a global message though without creating entries for everyone.
Here's some SQL:
SELECT M.*, MTU.*
FROM messages M
LEFT JOIN message_to_user MTU ON MTU.message_id=M.message_id
WHERE MTU.receiver_id={$UserID} OR M.message_type={$GlobalType}
ORDER BY M.created_on DESC
[EDIT]
Problem: Every user needs to have their own unique "read" status for global e-mails. You probably also want to give them the ability to "delete"/hide this e-mail so they don't have to be looking at it all the time. There is no way around this without creating either a row for each e-mail as it's going out, which is probably taxing to do that many INSERTS all at once...or better yet, don't create a status until it's read. This way, INSERTS for global e-mails will only occur when the message is read.
messages
message_id
message_type
sender_id
timestamp
message_recipient
message_id
user_id
message_status
message_status_id
message_id
user_id
is_read
read_datetime
is_deleted
deleted_datetime
SELECT M.*, MR.*, MS.*
FROM messages M
LEFT JOIN message_recipient MR ON MR.message_id=M.message_id
LEFT JOIN message_status MS ON MS.message_id=M.message_id
WHERE
(MS.message_status_id IS NULL OR MS.is_deleted = 0)
(MR.user_id={$UserId} OR M.message_type={$GlobalType})
ORDER BY M.timestamp DESC
[EDIT]
Whether to use message_type as a DB table or simply as settings within your code is partly a personal preference and partly your needs. If you need to query the DB and see the text "personal" and "global" directly from your query, then you want to use the message_type table. However, if you only need the "type" to handle your business logic, but don't need to see it in query results, then I would go with an "Enum" style approach. Enums are a C# thing...in PHP, the closest you've got is a class with constants...something like:
class MessageTypes {
public const Global = 0;
public const Personal = 1;
}
So, your query would be: WHERE ... message_type=".MessageTypes::Global."...

The one method can be to separate the global messages from the personal messages as I think you have tried to do already.
To effectively get a read status for a global message, you would need to add a table with a composite key containing the global_message_id and user_id together.
messages_tbl
- message_id | int(11) | Primary Key / Auto_Increment
- message_type | int(11)
- sender_id | int(11) | FK to sender
- receiver_id | int(11) | FK to receiver
- status | int(1) | 0/1 for Unread / Read
- message | text
- date | datetime
global_message_tbl
- g_message_id | int(11) | Primary Key / Auto_Increment
- g_message_type | int(11)
- sender_id | int(11) | FK to sender
- date | datetime
global_readstatus_tbl
- user_id | int(11) | Primary Key
- g_message_id | int(11) | Primary Key
- date | datetime
Alternatively merge the messages_tbl and global_message_tbl so they each user is sent a global message personally in a loop. This reduces your schema right down to one table.
messages_tbl
- message_id | int(11) | Primary Key / Auto_Increment
- sender_id | int(11) | FK to sender
- receiver_id | int(11) | FK to receiver
- status | int(1) | 0/1 for Unread / Read
- message_type | varchar(8) | Personal / Global / Company
- message | text
- date | datetime
- type | varchar(8)
If you want the ability to normalise your table a bit better, and make it easier to add message types in the future, move message_type back into its own table again, and make message_type a FK of the message_type_id
message_type_tbl
- message_type_id | int(11) | Primary Key / Auto_Increment
- message_type | varchar(8) | Personal / Global / Company
Update - Sample Table (1 Table)
message_tbl
message_id | message_type | sender_id | receiver_id | status | message | datetime
1 | personal | 2 | 3 | read | foobar | 12/04/11 00:09:00
2 | personal | 2 | 4 | unread | foobar | 12/04/11 00:09:00
3 | personal | 3 | 2 | unread | barfoo | 12/04/11 02:05:00
4 | global | 1 | 2 | unread | gmessage | 13/04/11 17:05:00
5 | global | 1 | 3 | unread | gmessage | 13/04/11 17:05:00
6 | global | 1 | 4 | read | gmessage | 13/04/11 17:05:00
user_tbl
user_id | name
1 | Admin
2 | johnsmith
3 | mjordan
4 | spippen
The above assumes users 2, 3 and 4 are general users sending messages to each other, user 1 is the admin account that will be used to send global messages (delivered directly to each user individually) allowing you to see the same information as if it were a personal message.
To send a global message in this format you would simply loop over the users table to obtain all the ID's you want to send the global message out to, then simply INSERT the rows for each user in the messages_tbl.
If you don't anticipate your users sending millions of messages a day as well as regular global messages to millions of users then the number of rows shouldn't be an issue. You can always purge old read messages from users by creating a cleanup script.

Related

Better way to design payment database with multiple payment methods

I am trying to make a payment/transaction database for a pretend online store (just trying to learn). 1 payment can purchase 1 to many items. 1 payment can only have 1 payment method.
To keep the example simple, there are 2 payment methods, PayPal and Bitcoin. Each payment method has different attributes, hence they must be different tables.
I have my payments table which tells me what transaction bought what item/s. However, you can see that if the paypal_idis NULL then the bitcoin_id column is not. This means there are a lot of NULL's which I think is not a good design. How can I have good design in a case like this?
paypal table
paypal_id | txn_id | buyer_email | amount
1 | 3sd7fgudf23sdf34 | john#mail.com | 50.00
2 | 45shfik45345fg2s | mike#gmail.com | 100.00
bitcoin table
bitcoin_id | txn_id | amount
1 | 34327yhujndreygdiusfsdf324 | 0.19203
2 | sdfgurjibdsfhubhsdfinjo332 | 0.04123
items table
item_id | item name | price
1 | ball | 50.00
2 | shirt | 50.00
payments
payment_id | item_id | paypal_id | bitcoin_id
1 | 1 | 1 | NULL
2 | 1 | 2 | NULL
3 | 2 | 2 | NULL
4 | 1 | NULL | 1
5 | 1 | NULL | 1
6 | 1 | NULL | 2
Your design is fine. But you might want to consider an alternative where you have a payment_transactions table and then related tables that use the same primary key:
create table payment_transactions (
payments_transactions_id int auto_increment primary key,
type varchar(255),
payment_datetime datetime, -- probably common to all payment methods
. . . other columns if you like,
unique (type, payments_transactions_id) -- this will be used for foreign key references
);
create table bitcoin_payments (
bitcoin_payments_transaction_id int primary key,
type varchar(255) generated always as ('bitcoin'),
. . . , -- columns specific to bitcoins
foreign key (type, bitcoin_payments_transaction_id) references payments (type, payments_transactions_id)
);
-- similar for paypal
Then your payments table can have a foreign key to payments.
This handles much of the data modeling issue;
You have proper declared foreign key relationships.
Only one column is needed in payments regardless of the number of types.
You can easily introduce new types.
This guarantees one type per payment (via the inclusion of type in the foreign key reference).
One downside is that you need to insert each transaction twice. First into the payment_transactions table and then into the proper table.
Payments are actually more complicated than you present. A more realistic data model would handle:
Transaction status.
Retries.
Partial payments.
Once you get the basic structure down, you might want to try adding in new capabilities.

The correct way of storing millions of Many-To-Many relations (pivot)

What I have
I have the next schema:
users table:
| id | name | ... | created_at | updated_at |
groups table:
| id | name | ... | created_at | updated_at |
messages table:
| id | text | ... | created_at | updated_at |
user_messages table (Pivot):
| user_id | message_id | sent_at |
user_groups table (Pivot):
| user_id | group_id | joined_at |
For now project is using only MySQL database.
Problem
Storing Many-To-Many is traditional way and it is okey. But in this case I am a little confused.
Groups can include unlimited users and a group can send 10-1000 messages (or more) per day. For example, let's take some basic numbers (not millions what in a real life can also be): 1 group, 10000 users, 100 messages per day. The relation row count per day: 10000 x 100 = 1000000. One million rows per day for one group, but groups count can also be thousands.
One idea that can come at once: Why do you need Pivot for messages? Answer is: The "target" sending option is required (For sending message only for x users, not for all).
Question
My question is: "What is correct way to store this kind of data?"
Maybe I need to use other Database system or maybe this numbers are not a problem for MySQL.

Alternatives to having nullable columns in primary key

I have a forum, where users can subscribe to receiving notifications when new threads are created. They can subscribe independently for each category in the forum. It should also be possible to subscribe to all categories, so that they do not have to specify each category if they want to receive notifications for all categories. (And also so that they will automatically receive notifications for any new categories that might be created in the future.) It is also possible to subscribe at different levels. For example one can subscribe to notifications o new threads only, or, in addition to the notifications, automatically subscribe to the new threads, with the effect of receiving notifications on new posts in the threads as well.
My first idea was to create a table containing UserId, CategoryId, and LevelId, having (UserId, CategoryId) as PRIMARY KEY. If CategoryId is NULL, it means all categories. This would allow for a base subscription to all categories, and then one could change the subscription level independently for specific categories.
+--------+------------+---------+
| UserId | CategoryId | LevelId |
+--------+------------+---------+
| 1 | 1 | 2 |
| 1 | 2 | 2 |
| 1 | NULL | 1 |
| 2 | NULL | 2 |
+--------+------------+---------+
The problem is that columns part of a PRIMARY KEY does not allow NULL values. I could of course use a separate value, such as -1 as "all categories", but this would break the FOREIGN KEY on CategoryId. Another idea is to use a UNIQUE KEY, which allows NULL values, instead of a PRIMARY KEY, but then there could be several rows with CategoryId = NULL for each user, since NULL != NULL in MySQL.
A different idea is to create a table using only UserId as PRIMARY KEY, and Categories as a bitmask for which categories the user is subscribing to. If Categories is NULL, this could mean all categories. This approach does not allow for a base subscription, overloaded by individual subscriptions. Also, the same subscription level is required for all categories, and there cannot be a FOREIGN KEY on Categories.
+--------+------------+---------+
| UserId | Categories | LevelId |
+--------+------------+---------+
| 1 | 3 | 2 |
| 2 | NULL | 1 |
+--------+------------+---------+
Are there any better suggestions for how to solve this issue?

Message Table, Don't show messages to who deleted

I have a mysql table named messages. It's structure below
id | sender_id | receiver_id | message | date | is_receiver_read | conversation_id
1 | 99 | 456 | hello | 2014 | 1 | 99x456
2 | 456 | 99 | hi) | 2014 | 0 | 99x456
When a sender or receiver delete messages from conversation i don't want to show to him messages from this conversation. How can do it?
When I add columns which named 'is_sender_delete' and 'is_receiver_delete' there is a problem. For first message sender is 99 but for second message sender is 456. When I update my table after an user press 'delete converstaion button' which column should I update?
If this structure is wrong, what is the alternative solution?
I think you need something like this...
CREATE TABLE subscriptions
(user_id INT NOT NULL
,conversation_id INT NOT NULL
,subscribed TINYINT NOT NULL DEFAULT 1
,PRIMARY KEY(user_id,conversation_id)
);

Query - Sending public and private messages to users

Need to implement the delivery of public messages for all users and personal messages.
Simplified tables:
messages
+---------------+---------------------------+
| Field | Type |
+---------------+---------------------------+
| id | int(10) unsigned |
| admin_id | int(10) unsigned |
| type | enum('public','targeted') |
| subject | text |
+---------------+---------------------------+
messages_read_status
+----------------+---------------------------------+
| Field | Type |
+----------------+---------------------------------+
| id | int(10) unsigned |
| message_id | int(10) unsigned |
| user_id | int(10) unsigned |
| status | enum('unread','read') |
+----------------+---------------------------------+
When sending public messages - in messages_read_status table records not created. For targeted messages - creating record with unread status. When message is read by user - setting read status.
Two filters on client side - Read/Unread. Message type does not matter for user.
Main task - create query to request Read or Unread messages for user, regardless of the type of message.
The main problem is to handle in query request for public unread messages, because there can be no records for them in messages_read_status . UNREAD query works properly while some user reads the message. Then new record in messages_read_status created and other users can't see this message any more. This situation I can't resolve. READ query works correctly.
SELECT messages.* FROM messages
LEFT JOIN messages_read_status
ON messages.id = messages_read_status.message_id
WHERE
{OTHER FILTERS} AND
(messages_read_status.`id` IS NULL OR (messages_read_status.`user_id` = $user_id AND messages_read_status.`message_status` = '$message_status'))
samlpe sql - http://sqlfiddle.com/#!2/d940d
Thank you
Way to get Unread (public + targeted)
SELECT messages.* FROM messages
LEFT JOIN messages_read_status
ON (
messages.id = messages_read_status.message_id AND
messages_read_status.`user_id` = $user_id
)
WHERE
{OTHER FILTERS} AND
((messages_read_status.`id` IS NULL AND messages.type='public') OR messages_read_status.`status` = 'unread')
AND for Read using simpler rules
{OTHER FILTERS} AND messages_read_status.`user_id` = $user_id AND messages_read_status.`status` = 'read'