I am creating a scheduler web app that stores its data in a mysql database, and right now I'm trying to figure out the best way to set up the tables in it.
It will support multiple users, and I want it to be able to handle a large user base (let's say many thousands).
Each user will have some usual data associated with them (username, password, preferences) and also their events.
Each user can have anywhere from 0 to 1000s of events, with each event having information such as start time, end time, name, etc.
So there will be many of these:
User
username
password
preferences
events
name
start time
end time
another thing is, i'd like each individual event to be queryable. I'd like to be able to modify event # of ___ user.
How can I set this up so it's not super complicated or really slow?
user table
user_id, username, password, preferences
Make user_id as the primary key.
event table
event_id, user_id, name, start_time, end_time
Make {event_id, user_id} a primary key.
This should do? If you are expecting thousands of events where many events can be duplicates but related to different users, you may create an event table without user_id and then create a new table to hold {event_id,user_id} combination.
PS: don't store the password in plain text; consider moving preferences to separate table.
Related
I want to revisit a project I made to store user data into a database and improve on the way it is stored. I currently went the hard way about it and stored user data in JSON format within a MySQL database field making it difficult to complete CRUD actions. The reason I did this was to keep all the user's data within the user's field. And was reasonably new to this.
I didn't want to store the data mixed with other user's data and as I thought there may be issues with increased users. for example,
If I had 1000 users with 500 rows of data for each, that's 500 000 rows to sort through when reading the data and displaying it on a web page. And is there a risk of mixing the data up or performance issues?
I basically just want a user database that stores the user's id, name, and credentials. Then another database that will store data from a user's activity(run). So at least 5 fields for each event: Time, location, date, duration, etc. And this will be saved for different events(runs) which could end up in the 100's over a period of time.
My question is, Should I design the table as above. Or would it be better to have a table for each user? Or are there other options that I have not explored?
Given the information shared, I believe below mentioned design may be suitable.
Create a Table called User_Details with columns as id (auto increment),user id, name and credentials.
Now create a User_Activity Table with these columns id, user_id, event name, data(json field).
Explanation:
The User Activity table will store the event data for you related to each user through user_id field to user_details table. The data which is a json field will help you to store all the fields for the event. As you are using json field in DB it will allow you to dump any number of fields for the event which may/may not be structured. You can then map this in your middle layer as required.
Also, in case you have finite number of events then you can also create a table called user_event_types and have column id, event name and then in user_activity table you can refer the id instead of event name.
I am using PHP , MySQL for Handling My site. I have a user table called user_table containing user_id PRIMARY and Now user can chat with other user. For that I am using a table called message_table. this table contains essential fields like msg_id , sender_id , reciver_id , replay_id etc. this works very fine.But I need to handle also guest users[Not registered] with this chat. how can I handle them. I inserted the guset_id as the mixture of entering time and his name to a table called guest_table. Now I can use this guest_table like user_table. Is that a good idea ?
But I need to handle also guest users[Not registered] with this chat.
These guests look to me like a special sort of user. I suggest you handle them as if they were users. You may wish to put a column called something like is_guest in your user table, and set it to 1 when you know the user is a guest.
Keeping a separate table, parallel to the user table, for your guests is NOT a good idea. It will greatly complicate your queries, especially when a person in your user table communicates with a person in your guest table.
Instead, put everybody in the user table, guests and registered users alike.
A nice little benefit: if you convert a guest to a registered user, all you have to do is flip the is_guest flag and let them specify their own username and other data. They get to keep their history.
I've been looking into the best way of storing an undetermined amount of information submitted by a user. A friend of mine suggested using nested tables, however these don't appear to be a thing in MySQL.
The application will allow users to store pieces of text information per day (each day is a blank slate so to speak)
What I have currently is
-Users
--ID
--email
--password
-Things
--UID (made from date and user ID)
--Thing1
--Thing2
This works fine. The UID is the users ID and the date combined (i.e 71420150404) as each day will be different but I'm open to changing this. The application checks to see if there are any entries for that UID and if there isn't, creates a new row.
The problem I have is I'd like the user to be able to select how many pieces of information they would like to add per day. So instead of the static 'Thing1, Thing2' the user could theoretically have this go up to 'Thing100', and I'm fairly sure adding these as columns isn't the best way to go about this.
I looked into if its possible to store an array in a cell and I'd access it like that through PHP but the research I came across all suggests I shouldn't do this. Creating a new table per user also seems very inefficient.
What is the best way to go about this?
I would create 2 tables:
entry table: id (auto increment), user id, timestamp - each time a user wants to store things a record is created and the id is retrieved using last_insert_id()
things table: id (auto increment), entry_id (foreign key to entry table), thing ( to store whatever the user wants to store)
If a user wants to store 10 things, then you create an entry record, then using its id you create 10 records within the things table. This way you are completely flexible on the number of things a user can store.
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.
I want to create a table called user_ports which will contain all the ports the user has opened in the database.
Instead of calling each colum as "port_80", "port_100"
I was wondering if its possible to enter it to a colum which will be called opened_ports as an array.
But if I would like to get all the users with port 80 opened, how can I do that?
As far as I can understand, you just need to have 2 columns in the user_ports table: user_id which will reference the appropriate user, and opened_port, which will describe the specific opened port. Then you should probably declare the (user_id, opened_port) pair as a primary key. With such table structure, you could select the ids of users that opened 80 port by the following query:
SELECT user_id FROM user_ports WHERE opened_port = 80;
You COULD store all of the ports opened by user as CSV in a single record, but this will:
require additional code that will deal with such trickery;
complicate and slow down your database queries;
denormalize your database (which should avoided).