I have not found a tutorial yet on the internet for what I am looking for.
Functionality I am after is a simple message send and retrieve function.
User 1 - Sends Message to User 2
User 2 can view messages in their Inbox
I know I will need 2 controllers one for Handling the message sending and the other to retrieve.
How would this type of system function on the DB side. Do i make a new Table for Inbox and so all messages are sent there with corresponding id of sender and receiver?
A simple 2 tables should be enough for this:
TblUsers (UserId, UserName, Password, FirstName, LastName)
TblMessages (FromUser [fk to tblUsers], ToUser [fk to tblUsers], Title, Content, SentDate, ReadDate, DeletedDate)
Note the DeletedDate is only relevant if you want to enable a recycle bin for messages.
If you want to enable sending the same messages to multiple users, you need a little different schema:
TblMessags(MessageId, FromUser [fk to tblUsers], Title, Content, SentDate)
TblRecipients(MessageId [fk to messages], RecipientId [fk to users], ReadDate, DeletedDate)
Since you require help with the table structure and not with the implementation itself, here is a possible scenario:
A table for all users
A table for all messages
Keep in mind that the users table and the messages table is up to you define the attributes you want to store in them. An initial approach could be:
CREATE TABLE users(userID int, username VARCHAR(30));
CREATE TABLE messages(messageID int, senderID int, recipientID int, title VARCHAR(50), content VARCHAR(1000));
Getting a specific user's Inbox could then be done using the following query:
SELECT *
FROM messages
WHERE messages.recipientID=XXXX
XXXX is of course the userID of the user's inbox you want. This would only get the message data. If you wanted to display the sender data you could join the result of the previous query with a query for senderID or recipientID.
Table structure can be changed according to what type of queries you're anticipating. I believe this should suffice as an initial approach, and then you can analyse whether you need to group or index data that gets requested a lot.
Do I make a new Table for Inbox and so all messages are sent there with corresponding id of sender and receiver?
Basically, yes.
I realize that you want to build a simple message table with one sender and one receiver. You might as well design the tables for one sender and multiple receivers, in case you want to expand your message system.
Let's make the user table.
User
----
User ID
User Name
...
And the message table.
Message
-------
Message ID
Message Sent Time Stamp
Message Text
A user can send more than one message and receive more than one message. So, we build a junction table.
MessageUser
-----------
Message ID
User ID
Sender / Receiver Flag
...
The primary key is (Message ID, User ID). You will also have a unique index on (User ID, Message ID). The primary key allows you to get a message to the user. The unique index allows you to build a list of previous messages for a user.
Related
I'm creating an application where there are multiple groups that contain a feed of messages. I need to know which message is read for X person. The feed should also be customizable per user.
I was thinking about using the following database structure:
messages
- id (PK)
- user_id (user that created the message)
- text
- group_id
- created_at
objects
- id (PK)
- user_id (user that should receive the object in his timeline)
- parent_type (can be `message` or some other resource)
- parent_id (the `id` of the resource based on the type)
- seen (boolean that indicates if the user has seen the object)
When a message is created for a group, I'll create a record in the messages table and create records for every member of the group in the objects table.
The only thing that is currently holding me back is, that there might be groups that consist of ~1000-2000 users at max. For every message created in those groups, there will be created 1000-2000 records in the objects table.
Will this be a problem and how could I solve this if it might be?
I was wondering if there is a simple way to do this query. I am building an API to send friend requests.
The end user will be sending me the email id of the person whom he/she wants to send a frnd request. I need to first check my user table against the email id the end user is sending and find out if the email id is present in my user table.
Case1:
Email id is present in user table. I then need to SELECT the user_id for this user AS friend_id.
And then insert into friend_request the user_id of the person calling the api and friend_id. I already get the user_id of the user calling the API whenever the API is called.
Case2:
Email id is absent in user table. I send an email invitation to this user to register into the app.
I am trying to do the mysql query of case1 in one single statement. I was wondering something like this,
INSERT INTO friend_request (user_id, friend_id) VALUES (1,4) WHERE EXITS (SELECT * FROM user WHERE email='black#sheep.com');
But obviously this will not work and has syntax errors, any idea on how I can achieve this?
Maybe just spelling error?
EXITS => EXISTS
INSERT INTO friend_request (user_id, friend_id) VALUES (1,4)
WHERE EXISTS (SELECT * FROM user WHERE email='black#sheep.com');
Ok i was told my last question was too wide so i try it more precise this time.
I need a Database Structure for a MessageBoard App.
I have 2 ideas but dont know which scales better.
Is there another possibility that is even better than my ideas?
There are Users, Messages and Groups.
All messages belong into at least one group but can be in more.
Users subsscribe to at least one Group and than can see all Messages of all Groups they belong to.
Users can create Groups at will.
Scale(theoretically):
Users: Millions
Messages: Billions
Groups: More than Users
I have two ideas right now:
Idea 1:
Table Users:
ID
All personal information...
GroupsSubscribed (string with all group IDs?)
LastUpdate (Date)
Table Messages:
ID
ImageURI
Text
Creator
Date
Groups
Answer_Messages_IDs (String with all IDs of messages that are an answer to this message)
Table Groups:
ID
GroupName
LastUpdate (Date)
Idea:
Message Get:
App gets every X seconds the Group-LastUpdate (DB call: Group)
If Group-LastUpdate > User-LastUpdate ->
Select all Messages where Groups contain Group and Date > LastUpdate (DB call: Messages)
Message Write:
App writes Message belonging to more Groups
Save Message in Message Table (DB call)
Update Group Table LastUpdate (DB call)
-----------------
Idea 2:
Table Users:
ID
All personal information...
GroupsSubscribed (string with all group IDs?)
NewMessages (string with MessageIDs?)
Table Messages:
ID
ImageURI
Text
Creator
Date
Groups
Answer_Messages_IDs (String with all IDs of messages that are an answer to this message)
Table Groups:
ID
GroupName
UserIDs (string with all user IDs)
Idea:
Message Get:
App gets every X seconds the User-NewMessages(DB call: Users)
If User-NewMessages != "" ->
Select all Messages where ID in List of NewMessages (DB call: Messages)
Message Write:
App writes Message belonging to more Groups
Save Message in Message Table (DB call: Messages)
Get Groups-UserIDs for every Group (DB call: Groups)
Update every User with new Message ID (DB call: Users)
This is an exercise in database normalization as #Paul Spiegel indicates above.
You would create something like the following:
Users
UserID PK
ImageURI
... personal user informational columns ...
Messages
MessageID PK
Text
UserID FK -> Users(UserID) // Message Author (Creator)
Date
Replies
MessageID FK -> Messages(MessageID)
ReplyID FK -> Messages(MessageID)
PK (MessageID, ReplyID)
Groups
GroupID PK
Name
Description
UserID FK -> Users(UserID) // Group Moderator -- I'm just adding this one in for fun.
User_Groups
UserID FK -> Users(UserID)
GroupID FK -> Groups(GroupID)
PK (UserID, GroupID)
Message_Groups
MessageID FK -> Messages(MessageID)
GroupID FK -> Groups(GroupID)
PK (MessageID, GroupID)
I moved ImageID from Messages to Users on the assumption that it is a user Avatar. If it is really something else associated with a message, then move it back.
There are three application integrity rules in addition to the PKs and FKs already included.
AIR #1 - The existence of a row in Messages implies at least one matching row in Message_Groups.
AIR #2 - The existence of a row in Users implies at least one matching row in User_Groups.
AIR #3 - A given ReplyID can only appear once in Replies. This keeps adjacency list semantics preventing a generalized many-to-many association and enforcing a hierarchical association.
The database join logic and application code is left as an exercise to the reader.
I have 2 ways for users to create an account on my website.
a. Normal Registration Form (email, password)
b. Registration via Facebook Connect (fb_userid, email)
Which is the best practice to implement this using MySQL (InnoDB engine) ?
My approach:
[USER]
user_id
user_type (normal/facebook)
[USER_NORMAL]
user_normal_id
user_id
email
password
[USER_FACEBOOK]
user_facebook_id
user_id
email
fb_userid
What do you suggest?
This single table would be more simple (in my opinion):
user (user_id, user_email, user_password, user_fbid)
You don't need a "type" because you can use a CASE to determine if user_fbid is NULL then it's a "normal" account, else if user_password is NULL then it's a Facebook account.
I would have two tables.
One table should contain basic user information:
user (user_id, user_email, user_password)
The other table should be generic and link 3rd party accounts to these users. Example:
user_ext (type, user_id, uid)
The type field should contain the type of service (in this case Facebook), and the unique identifier for the service (in this case the Facebook User ID). It should then link back to the user_id.
This strategy will then allow you to add additional services that users can authenticate against in the future.
I would keep everything on one table and differenciate them by if they have a Facebook Id or not.
If those are the only fields then it's probably easiest to put all the fields in one table and have NULLs as appropriate.
However, if you want a normalised design you would go for something like this:
[USER]
user_id (PK)
email
(Other fields common to both)
[USER_NORMAL]
user_id (PK, FK to USER.user_id)
password
(Other fields specific to 'normal')
[USER_FACEBOOK]
user_id (PK, FK to USER.user_id)
fb_userid
(Other fields specific to FB)
If 'password' is the only field specific to 'normal' users and there are many fields specific to FB users then a compromise might be to have two tables: USER (as above but containing 'password') and USER_FACEBOOK
I would probably prefer to keep all users in 1 table. You can have fields that are null if that user's type doesn't have that field. For example fb_userid can be null if the user is normal.
[USER]
user_id
user_type (normal/facebook)
email
password
fb_userid (can be null: yess)
I am trying to create a subscription based payment module for a project.
There are three plans
Will cost 49$ but right now it will be free till we acquire users.
499$ which will have 15 days trial
799$ which will also have 15 days trial.
We are using Stripe for Payment Integration.
I have a users table with as follows
users(name, email, password, ....)
Now i want to store the following
Define and Maintain Plans
Which plan a user is subscribed to
When a user is subscribed to a plan - details regarding the payments - upgrade - downgrade etc.
Can some one share how i can do it via Mysql tables and if i am missing any key information that i need to store ?
Here it is a little sketch of what i would do in this scenario :
Tables
Users
id, nameemail, password, ...
MaintainPlans
id, user_id, name, ...
Payments
id, name, user_id, ...
Operations
id, type, user_id, name, ...
Notes
The user_id field reference of course the id primary key of the user table
Each tables can,of course, contains more columns containing more information or relations(i have inserted only the essentials.
The Operations type field should contain an enumeration with the possible value (upgrade, downgrade), could be defined into and enumerator or into another table referenced (even better) ...