How do I link or add the field with all my users called "username" from my main table to another table so I can run checks and compare values without having to add a ton of rows to my main table? This would be a much cleaner and more organized setup.
Table called login_users. This is my main table that stores their basic information
username email password
Anthony user#email.com
Josh user#email.com
Tsuyoshi user#email.com
Table 2 called badge_status. This table will hold their status with whether or not they have unlocked an achievement on my site. I want to bring in the usernames.
username badge1 badge2
Anthony locked unlocked
Josh unlocked locked
Tsuyoshi unlocked locked
Also, could table 2 automatically be updated with a new user when they sign up since all new sign ups are imported into the first table. As a side note, I am using phpmyadmin.
Thanks for any help with getting this set up. Very much appreciated.
I think you should normalize your data by using the following schema instead:
login_users [Table]
username
email
password
badges [Table]
BadgeId int PRIMARY KEY
BadgeName
... (any other relevant columns)
users_badges [Table]
username (foreign key constraint to username column on the login_users table)
BadgeId (foreign key constraint to BadgeId column on the badges table)
This will allow you add as many badges as you want without having to ever change your database schema or scripts.
I don't really understand why you are separating out these tables. In theory, there is a one-to-one relationship between the two. Your query "could table 2 automatically be updated with a new user when they sign up since all new sign ups are imported into the first table" further supports the argument why splitting these tables simply creates unnecessary overhead.
Other sources of overhead include overly complicated JOINs to get the data out and the need to add an additional unique constraint on badge_status.username as well as a foreign key.
If you truly wish to separate out these tables, I would suggest the following setup instead which makes querying for specific badges and adding new badges very easy:
login_users: username, email, password, ...
badges: id, name, description, ...
users_badges: username, badge_id, status, unlocked_date, ...
Related
I want to create a user into User table.
These are my process.
continue when email and nickname are not exist
creates a user
I think if I didn't lock the User table while creating a user then email and nickname can be duplicated.
Any ideas?
Avoid locks where possible. Instead, use a unique index, and simply insert the user. If the user or email exists, your query will return an error similar to:
Error Code: 1062. Duplicate entry 'john.doe#example.org' for key 'unique_email'
This should be done with 2 separate indexes. One for email, and one for users. This has the following advantages, and almost zero disadvantages:
It enforces database consistency. At no point will 2 users have the same email address, nor the same username.
It avoids unnecessary locks.
It avoids technical debt. Let's say down the line you add a user importer. In the importer you fail to check for duplicate accounts, or add in locks, or forget to check if the username or email exists. Your importer will work, and your database will now contain entries that duplicate each other.
I'd try to create a combined unique key on email and nickname
CREATE UNIQUE INDEX some_index_name ON user_table(email , nickname)
Edit: To address the comments below, we should as well create 2 more unique indexes for email and username, to make sure 2 users with separate emails can share the same username and vice versa.
I've almost completed my very complex project, then realized I had one issue still hanging me up. How do you (or is it even possible) to have the foreign key auto update (to reflect the parent) for each child table?
I guess I should mention the main site is built through Joomla. Everything I will be referring to in this post resides outside of Joomla but on the same domain, with the exception to the user profiles.
For instance...
I have table dataCompany that stores the company information. This table will be a child table to the userProfile table. Now, userProfile table has an auto-incremented column (user_id) and I created a column by the same name in dataCompany (but not auto-incremented). I want the user_id in dataCompany to auto fill to match that from userProfile.
The user will be logged in when entering data into dataCompany, which I thought would make it easier to autofill the user_id foreign constraint. However, I still get the invalid error.
Perhaps I'm missing something, but I was under the impression foreign keys were the only way to hold separate tables together.
EDIT:
I'm pretty sure I didn't explain what I'm doing very well.... so here's another try.
I have a website. The user will sign up for said website. That creates user_id in mysql database. I have a form the user will fill out, and the information will be stored in dataCompany. This table has primary key of companyID but also has column user_id. I want the data the user inserts into dataCompany to be associated with the user data tied together by user_id. Now, when the user signs up the user_id is auto-incremented. I can't have the user putting in their user_id when filling out their company information (as they don't know what it is)... that's where the 'auto update foreign key' comes from. I just want it to replicate what is already in the parent table (userData).
I'm designing a MySQL database with some tables for a clinic and I need three different user types: admin, medic and patient.
What I did was to create a table called users where its columns are precisely the common fields shared by admins, medics and patients (there is of course a primary key called id_user which auto increments every time a user is added).
Then I created three tables regarding the specific data for each user type: admin, medic and patient in which I have a field called id_user which is a foreign key to id_user in the table users.
When I tried to establish the foreign key constraint for the three user type tables, phpMyAdmin doesn't allow me to set ON DELETE as "SET NULL" (I think that would make sense because if I delete a user from the users table then it should automatically set the fields as NULL in the medic, admin or patient tables, right?) and gives me the error "relation has not been added".
Doubt 1: What's happening here that I'm not aware of?
Doubt 2: Should I forget this way of relating tables and simply add the specific fields for each user type in the users table although some users will have some fields set as NULL?
Here is an image illustrating my database:
You should use Cascading Deletes instead of setting fields null, if you delete a user you want them gone if you null out the data you'll just have tables filled with nulls.
Also from what i understand you created 3 tables for each of the permission levels if this is the case you should maybe handle that in code with conditions checking the permissions level
i wanna have a Users details stored in the database.. with columns like firstname, last name, username, password, email, cellphone number, activation codes, gender, birthday, occupation, and a few other more. is it good to store all of these on the same table or should i split it between two users and profile ?
If those are attributes of a User (and they are 1-1) then they belong in the user table.
You would only normally split if there were many columns; then you might create another table in a 1-1 mapping.
Another table is obviously required if there are many profile rows per user.
One table should be good enough.
Two tables or more generally vertical portioning comes in when you want to scale out. So you split your tables in multiple tables where usually the partiotioning criteria is the usage i.e., the most common attributes which are used together are housed in one table and others in another table.
One table should be okay. I'd be storing a hash in the password column.
I suggest you read this article on Wikipedia. about database normalization.
It describes the different possibilities and the pros and cons of each. It really depends on what else you want to store and the relationship between the user and its properties.
Ideally one table should be used. If the number of columns becomes harder to manage only then you should move them to another table. In that case, ideally, the two tables should have a one-one relationship which you can easily establish by setting the foreign key in the related table as the primary key:
User
-------------------------------
UserID INT NOT NULL PRIMARY KEY
UserProfile
-------------------------------------------------------
UserID INT NOT NULL PRIMARY KEY REFERENCES User(UserID)
Depend on what kind of application it is, it might be different.
for an enterprise application that my users are the employees as well, I would suggest two tables.
tbl_UserPersonallInformation
(contains the personal information
like name, address, email,...)
tbl_UserSystemInformation (contains
other information like ( Title,
JoinedTheCompanyOn,
LeftTheCompanyOn)
In systems such as "Document Managements" , "Project Information Managements",... this might be necessary.
for example in a company the employees might leave and rejoin after few years and even they will have different job title. The employee had have some activities and records with his old title and he will have some more with the new one. So it should be recorded in the system that with which title (authority) he had done some stuff.
Apologies if I wasn't able to describe the problem accurately in the title. My scenario is as follows.
My site operates as a platform to connect vendors and buyers. Vendors list down the goods/services they have available and buyers are able to purchase goods/services from them.
New buyer (user) registration is straightforward in that their information gets stored in users tables (users, user_profile, user_history etc.) tied together with a unique user_id. What I'm having difficulty wrapping my head around now is that I require vendors to register as well (for verification purposes,) and that vendors can also be buyers.
My users table is like so:
user_id <--- primary key
name
email
...
and a related table may look like so:
transaction_id
user_id <--- foreign key
date
amount
...
My initial thought for the vendors table:
vendor_id <--- primary key
user_id <--- foreign key
vending_name
registration_number
...
and a related table:
product_id
vendor_id <--- foreign key
name
price
...
My question is, would it be best to have this vendor_id to link up all the vendor-related tables or should I stick with using the user_id for everything?
Thanks.
It depends.
Think of this scenario, could a user ever become a vendor (or vice versa?) if so then it's best to plan your data models around a base user and add attributes or flags (in a separate table or field). This way, you can add/remove privileges.
i.e. Have a separate tables called "flags" "flagmappings"
//flags
flag_name <--- 'Vendor', 'User'
//flagmappings
user_id <--- foreign key
flag_id <--- foreign key
This structure gives you a few benefits:
For any given user you can search flagmappings and then determine what privileges a user might have.
All your login/authentication logic is the same for all users/vendors (i.e. you don't have to split/special case different tables if it's a vendor or a user, all the base information is in the same place).
If a user needs to become a vendor or vice versa you simply add that flag to the user.
If you need to create yet another type of user (i.e. administrator, manager, etc.) it's just another entry in the flag table.
If I were you, I would just stick with the users table for everything (as long as you don't have a gazillion vendor-specific fields). It just makes things cleaner. Then, you might have a 'is_vendor' field in the users table.
Or if you want to go even more sophisticated, you could implement roles with something like this:
users Table
id
firstname
etc...
groups Table
id
title
etc.
user_groups Table
user_id
group_id
Personally, I would go with the second option because it allows for more role-based permissions, such as admin, editor, moderator, buyer, seller, super-buyer, super-seller, etc.