Suppose I have an app that send notifications to users through GCM. Each user can choose out of several topics that it can be notified about.
I have a user table in which I store the GCM registration IDs of the users in addition to my own user_IDs, and I have a topic table where I store the available topics to choose from.
I also have a user_topics table where I store the user ID and the topic ID, so when a user choose a topic, it inserts a row to that table with the user ID and the ID of the chosen topic.
When I send the notifications, I query the user_topics table for all the user IDs that are assigned to the topic which I notify about and then query the user table to get the respective GCM registration IDs.
This can triple the duration of the notification sending process compared to a case where I would store the registration IDs not only in the user table but also in the user_topics table so I wouldn't have to query the user table when sending.
I know that a good practice is to store the registration IDs in the user table only, but in the notifications world the most important thing for me is to send the notification in the shortest time possible.
Will it be right to store the registration IDs in the user_topics table to shorten the sending process?
Related
I am working on a practice project its about Buy & Sell. I have a confusion about the tables I have in my database for users who are registered with and they have accounts.
My Pencil planning is that a registered user can also Post an ad from their dashboard and an unregistered user can also Post an ad directly without having an account.
My Question is that should I have separate tables like
ind_laptops(ind for independent) = Table for unregistered users for their ads and they can post an ad without having an account; and
users_laptop with user_id as a foreign key = Table for users who are registered with us and have accounts they can post right from their accounts dashboard.
I am confuse but i think that its a good practice and can help me a lot in future when filtering the data against per User records.
I would hold only single table.
Mark unregistered users with id -1 , or create flag field that means whether it is guest post or not.
The reasoning behind it is - that the only difference is if it is registered user or not, the data is the same.
I'm writing an app that stores messages sent to users in a mysql database. These messages can have keywords that will be replaced by users data. at this time the dilemma that exists is what is the best way to store messages.
I have two options:
Store the original message (including keywords) in a table, and recipients in another. when i need to get the message, can be processed before it is displayed. the biggest problem is that the message will be different each time the user changes his own data.
Store the original message (including keywords) in a table and another table to store the recipients and the message the user is received. the disadvantage is the possible duplication of data, which can be a headache if the same message is sent to 20,000 users.
I would suggest several tables.
message - table, which will store message text
user - table to store user account information
mail - table to store message_id, user_id_from, user_id_to, is_read and other attributes to be associated with the specific conversation.
In a message table you should store message templates. When the message is fetched for display, it should be rendered. If you will need caching, you will be able to add rendered version of a message to the mail table (if rendering will consume too much of the resources).
I have a bunch of users in a project in the users table. I have a second table I use for notifications. When a user gets a notification for him, its added to the notifications table with his user_id and a read (true/false) flag.
Now, if I want to add a notification for every user (such as site going offline, etc), how would I add a row for every user in the users table? The new rows would be exactly identical with the exception of the auto_incremented row id but each new row would have to specify the user id.
Of course I could write a script in php to generate a ton of sql queries to do this and send them all at once using a multi-query insertion, but that seems computationally expensive if I have thousands of users.
Conceptual query:
FOR users.id as user_id
INSERT INTO notifications VALUES (,user_id=user_id,msg='We will be going offline at 5:00!',read='0')
Is that do able?
Thanks!
If you have thousands of users, it doesn't matter to generate thousands of SQL querys, and send it to your MySQL server.
But things will change if you have millions of users.
One affordable choice is, write a notification to a table, for example, system_notifications. Display not only notifications but also system_notifications on your webpage.
And then save the ids for the users who have already read these notifications.
e.g.
system_notifications table
| id | message |
system_notifications_read_users table
| id | user_id |
Then, you can only operate your database when the user read the notifications.
And when your system notification expired, such as you have finished your downtime, you can remove it from both of tables said before.
I have 4 tables,one is credentials(it holds an id, email and password), the other 2 are for business users and regular users of the app.
The business users table holds crID(foreign key)name,lastname,address etc...
The regular users table holds crID(foreign key),name,lastname etc...
The 4th is the booking table, it holds a bookingID, bookedfrom,bookedfor(the last 2 being foreign keys that point to the credentials table).
If a regular user registers in the site he closes a bookingslot and that is stored in the booking table, his name,last name are stored in the regular users table and his credentials in the credentials table.
The business user table just holds the business user for which a booking is made by the regular users.
Here is a graph:
db image
The question is what to do if a regular user does not choose the web to make the booking but makes a call. The business users are given the option to make the booking "manually" also. I am just having difficulty how to integrate that in the db.
As I see it I need to make the following:
Create a booking slot in the bookings table
Create a new regular user entry in the regular users table and at the same time create another column that would indicate if the user is registered or not.
create an entry in the credentials table but without password/email since this he will not be a registered user...he just made a booking using the phone.
WHat is your opinion.If you want I will post some show create statements. I think I made my point.
I would personally merge business users, normal users and optionally credentials in one single userstable.
Since I don't see the need of two seperate tables for your users, it would simplify drastically your data model. You just need a flag to determine if the user is a business user or a normal user.
For the rest, I think that having a null password is enough to determine if the user hasn't registered yet.
My site enables communication between both registered and non-registered users. I'm trying to determine the best practice for storing non-registered users in the database. My initial schema was as follows:
Users
------------
user_id
device_id *Unique* (this is for mobile app users)
email *Unique*
phone *Unique*
first_name
last_name
image_url
date_joined
UserNames (Users have custom names for each group potentially)
-------------
name_id
user_id
group_id
first_name
last_name
Further details of how the app works:
Users register and create groups/lists which include both registered and non-registered users
Messages are then sent to members of the groups/lists
Note: registered users can add non-registered users to lists without their explicit approval.
I chose the design listed above because emails, phone numbers, and device IDs would be unique. However users may have different names/nick names for each of the users, hence the UserNames table. However it's not clear to me whether or not storing non-registered users should be stored in the Users table given that they aren't technically registered users of the site.
Should I be storing the non-registered/external users in a separate table? Let me know if you need me to clarify anything.
Whether you segregate unregistered user into their own table is a design decision probably only you can answer. It would probably depend on how these different user types are used throughout your application. It could be something as simple as having a tinyint field with 0 or 1 values to indicate a user is registered.