The site I'm working on has 3 different types of users: admin, applicants, reviewers. Each of these groups will have some basic info that will need to be stored (name, id, email, etc) as well as some data that is unique to each. I have created a users table as well as a table for each of the specific groups to store their unique data.
users: id, f_name, l_name, email, user_type
users_admin: id, user_id, office, emp_id
users_applicant: id, user_id, dob, address
users_reviewer: id, user_id, active_status, address, phone
If a user with user_type of "1" (applicant) logs in I will need to JOIN to the users_applicants table to retrieve their full record. I tried using a UNION but my tables have vastly different columns.
Is there a way to, based on a user's type, write a conditional query that will JOIN to the correct table? Am I going about this completely the wrong way?
Thank's in advance for your help!
Well, in the end your tables are already flawed. Why even have a table for each type? Why not put all those fields into the users table, or maybe a user_details table (if you really want an extra table for non-general data fields)? Currently, you're actually creating 4 independent user tables from a relational point of view.
So why do the type-tables have a surrogate key? Why isn't the user_id already the (only) primary key?
If you changed that, all you would need is the user id to retrieve the data you want, and you've already got that (or you wouldn't even be able to retrieve the user type).
Either you do it programmatically, or you can do this with a series of CASEs and LEFT JOINs.
For simplicity's sake let's do this with a table users where you can have a user of type 1 (normal user), 2 (power user) or 3 (administrator). Normal users have an email but no telephone, power users have an address and a field dubbed "superpower", and administrators have a telephone number and nothing else.
Since you want to use the same SELECT for all, of course you need to place all these in your SELECT:
SELECT user.id, user.type, email, address, superpower, telephone
and you will then need to LEFT JOIN to recover these
FROM user
LEFT JOIN users_data ON (user.id = users_data.user_id)
LEFT JOIN power_data ON (user.id = power_data.user_id)
LEFT JOIN admin_info ON (user.id = admin_info.user_id)
Now the "unused" fields will be NULL, but you can supply defaults:
SELECT
CASE WHEN user.type = 0 THEN email ELSE 'nobody#nowhere.com' END AS email,
CASE WHEN user.type = 1 OR user.type = 2 THEN ... ELSE ... END as whatever,
...
Specific WHERE conditions you can put in the JOIN itself, e.g. if you only want administrators from the J sector, you can use
LEFT JOIN admin_info ON (user.id = admin_info.user_id AND admin_info.sector = 'J')
The total query time should not be too bad, seeing as most of the JOINs will return little (and, if you specify a user ID, they will actually return nothing very quickly).
You could also do the same using a UNION, which would be even faster:
SELECT user.id, 'default' AS email, 'othermissingfield' AS missingfieldinthistable,
... FROM user JOIN user_data ON (user.id = user_data.user_id)
WHERE ...
UNION
SELECT user.id, email, 'othermissingfield' AS missingfieldinthistable,
... FROM user JOIN power_data ON (user.id = power_data.user_id)
WHERE ...
UNION
...
Now, if you specify the user ID, all queries except one will fail very fast. Each query has the same WHERE repeated plus any table-specific conditions. The UNION version is less maintainable (unless you generate it programmatically), but ought to be marginally faster.
In all cases, you'll be well advised in keeping updated indexes on the appropriate fields.
Instead i will suggest you reconstruct you tables structure like this.
Create a table
users_types :
id
type
Then create another table users with a foreign key
users :
id
f_name
l_name
email
office
emp_id
dob
address
active_status
phone
users_types_id
And now when you need to insert data insert null in the fields which are not required for a particular user. And you can simply fetch records on the basis of id. Also using left join will give you the name of user type.
Related
Use case background: I'm using a WordPress site to manage memberships, and the ID Card software on my PC will connect to a table to generate its information. It can connect to only one table.
Goal: I need a table called "id_card" that contains the columns (member_number, first_name, last_name, exp_date), and it's populated with users that have been modified within the last month ("membership" table has a column titled "moddate" that I can use as the criteria).
Challenge 1: I need to pull exp_date from table "membership" and the other values -- member_number, first_name, last_name -- all come from a table called "wp_usermeta" (a default table for WordPress). Both source tables contain user_id to associate the information to the same user account. I believe this requires some kind of LEFT JOIN, but I haven't been able to get it to work.
Challenge 2: the bigger challenge: wp_usermeta table contains all the different user attributes in ROWS instead of COLUMNS. So the columns are titled "user_id, meta_key, meta_value" and there might be 30 rows for a single user. If I want to SELECT user 49's first name, it looks something like this:
SELECT meta_value FROM wp_usermeta WHERE user_id=49 AND meta_key='first_name'
Question: How do I write this query so it will INSERT INTO the table "id_card" the values from the two tables, using the user_id to keep it all lined up, especially when I can't use solely the user_id as a unique identifier (i.e. the only way I know to narrow it down to someone's first name is use both their user_id and the meta_key) in the wp_usermeta table?
There is a major problem with your wanting to copy data. If the user changes their data then your copy will be out of date. If you look at the wp_users table there is a ID field. This points to the relevant entries in the wp_usermeta table (user_id)
SELECT `wp_users`.*
, `wp_usermeta`.*
FROM `wp_users`
INNER JOIN `wp_usermeta` ON (`wp_users`.`ID` = `wp_usermeta`.`user_id`)
WHERE ID=1;
Now this will return multiple rows. If you want a single record then you'll need to do
SELECT`wp_users`.*
, (SELECT meta_key FROM wp_usermeta WHERE meta_key='wp_user_level' AND user_id=1) AS user_level
, (SELECT meta_key FROM wp_usermeta WHERE meta_key='show_syntax_highlighting' AND user_id=1) AS syntax_highlighting
FROM `wp_users`
WHERE ID=1;
Just repeat the subquery statements for as much info that you want to return. The subquery can only return a single value.
I am currently making an android app which uses a feed to display statuses made by users. I have three tables within the same database, each has username either as a primary or unique key column, but each table has different information relating to that user.
For instance, the first table ===>> tbl_users:
username
fname (first name)
mname (middle name)
lname (last name)
etc. (the list is long)
The second table ===>> tbl_userprofilepictures:
profilepictureID
username
profilepicturepath
The third table ===>> tbl_user_feed:
postID (the status' unique ID)
username
status
imagepostpath (the path to the image uploaded with the status)
timestamp
I want to be able to search for the username across all three tables and display the relevant information relating to them on their post. For example I will need their name and surname for tbl_users and I will need their profilepicturepath for tbl_userprofilepictures as well as their status, imagepostpath and timestamp from tbl_user_feed.
Would I need to do this in a seperate PHP file or in the app itself? PS I'm fairly noob at PHP so please feel free to help a bro out.
May the force be with you.
You can use JOIN.
What is JOIN ?
An SQL JOIN clause is used to combine rows from two or more tables, based on a common field between them.
Source : w3schools.com Joins
Here is the sample I made base on your tables given. For these one our common field is username.
SELECT CONCAT('a.fname', 'a.lname'), b.profilepictureID, c.status, c.imagepostpath, c.timestamp
FROM
tbl_users as a
LEFT JOIN tbl_userprofilepictures as b ON b.username = a.username
LEFT JOIN tbl_user_feed as c ON c.username = a.username
Using Alias (table_name as custom_name) is a good practice in joining the tables
I am creating a site that allows users to view desired 'teams' and can then join them with the click of one button.
I have my users table which contains: user_id, user_name, team_id
Then, I have my teams table which contains: team_id, team_name, team_players
How would I go about having the users to join a group, each user can also only be in 1 team at a time.
If you want each user to be able to join multiple teams, and each team to have multiple users, then you need a "join table."
Table teams_users would contain team_id, user_id. You can make a composite primary key on team_id, user_id (preventing a user from joining the same team twice).
Then you can get a team with:
SELECT * FROM users t1 right join teams_users t2 ON t1.team_id = t2.team_id WHERE t2.team_name = 'the rascals'
Even if you only want players to join one team at a time, you might still want to use the join table in case you ever change your mind. It would be very easy. To only allow one team per user, put a unique constraint on user_id in the join table. If you later decide you want to allow multiple teams, you just remove that constraint.
If a user tries the "join team" action, you simply check for the user_id's existence in the join table.
SELECT * FROM teams_users WHERE user_id = $user_id
If it does exist, you retrieve its matching team_id and tell them, "sorry, you are already in team 'the rascals'. You must leave that team if you want to join another." If they drop their team, you simply do:
DELETE from teams_users WHERE user_id = 5
If they add a team, you just do:
INSERT INTO teams_users ($team_id, $user_id) #// (assuming PHP variables).
The INSERT query will only work if they are not already in a team. If they are you would get an error message. You could also look at "INSERT ON DUPLICATE KEY UPDATE ..." queries. But I would advise against that because you want to warn users before they change teams.
You should start by adding the team_id field to the users table as a foreign key and allow it to be NULL.
Then you would display the team names in an html form with a radio button for each team.
In a PHP file (which should be set to the action of your form) create an if statement based on the values you assigned to each radio button. In each if block, execute a sql UPDATE statement that will add the appropriate group_ID to the right user instance.
From what I've been reading online, I understood that it's better to split the data into more tables, if possible because of the access times.
Right now I have a table in which I am storing usernames, passwords and join date
This is how my table looks:
'user'
'user_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
user_username VARCHAR(80) NOT NULL,
user_password VARCHAR(255) NOT NULL,
user_join_date INTEGER UNSIGNED NOT NULL,
PRIMARY KEY (user_id) ');
I am trying to create a new table called profiles in which I want to store first name, last name, email, age and gender. What I think is that I need a one-to-one relationship, so I should be using the user_id but I'm not really sure how to implement it.
Should I create another table called profiles with
profiles
profiles_id
first_name
last_name
email
age
gender
and another one which should be the relationship ? e.g.
user_profiles
----------
user_id
profiles_id
Is this right? How would the SQL look for the user_profiles?
Thanks
Don't split the tables. Just add the new columns to your existing user table. You might find later on that splitting tables is a good idea based on actual queries and usage patterns but until you have that kind of data, keep things simple.
If you must create a profile table, don't create a user_profiles table. That would allow an m-to-n relationship which is probably not what you want. A simple user_id column in profiles is better. In fact, it could be both a foreign key and the primary key to make sure that each user row only have one and only one profile row (although by splitting the tables you might still have a user with no profile).
Usually, you create an association table, like user_profiles you have described when one user could have more than one profile, and/or one profile could belong to one or more user.
As you have said, here you have a one-to-one relationship between user and profile. So, you can simply add a user_id column to your profile table, and define it as a foreign key to user table.
Then, a simple JOIN will allow you to query both tables at the same time:
SELECT u.*, p.*
FROM user u
JOIN profile p ON u.user_id = p.user_id
Add a new field in the User table, ProfileId, and set it as Foreign Key (FK). Each time you create a User, you have to assign to it a profile (which will be the ProfileId PK from profile table).
If you want to see also the profile information of a user, you have to do a join
Select username, first_name,second_name
From user u, profile p
Where u.profileId = p.profileId
this
user_profiles
----------
user_id
profiles_id
is used in a many-to-many relationship. By example, you want to assign to an admin some privileges, but those privileges can be also assigned to more admins. Then, you have to create a 3rd table to solve this problem. Here is an example, but you don't need to do this.
You could add a user_id field to your profiles table and JOIN the tables on user_id.
SELECT user.user_username, ..., profiles.first_name, ...
FROM user
INNER JOIN profiles
ON user.user_id = profiles.user_id
This should fetch data combining information from those rows where the JOIN condition is met (i.e. user.user_id = profiles.user_id).
It is true that having more than one tables is a good idea. I am not sure what you mean about access time, but there are other advantages.
- Your users database containing passwords etc is "sacred", you never change its structure and you limit the rights to it (read, write) to the strict minimum.
- You can then have several "satelites" tables such as profiles, private messages, etc which are more flexible, less sensitive and which you can change all the time.
About your question per se, there is no need for a separate table with the relationships. In fact is a very bad idea which will complicate your queries and doesn't have any advantage. Instead, in your profiles database you will have one column that refers back to the user id.
users
--------
id
user_name
email
password
users_profiles
---------
id
user_id
favourite_animal
Table user
user_id |user_username |user_password |user_join_date |profile_id
Table profile
profile_id |first name |last name |email |age |gender
When selecting a user by user id:
SELECT u.*, p.* FROM user AS u INNER JOIN `profile` AS p ON u.profile_id = p.profile_id WHERE u.user_id = 1
But a user should only one gender, one age, one name and surname. Maybe e-mail adresses might be many. I suggest you there is no need to join tables which have a 1-to-1 relation. Instead merge those tables.
I'm having some trouble figuring out how I should build my database for this project i'm currently working on. Fishing-related.
I'm just not sure how to set up my tables.
Table 1(ID, username, email etc)
Table 2(fish, weight, length etc)
How do i join these two tables? Should I have a column named ID in the 2nd table aswell? Because I need to know which user uploaded what fish. I'm just not sure how to do that.
Any help is appreciated.
Yes you have to, and that is called Relation Databases this is example
Users (UserID, UserName, Password)
Fish (FishID, UserID, FishName, Length, Weight)
and then you connect them using UserID
select u.UserName, f.FishName, f.Length, f.Weight
from Users u
LEFT JOIN Fish f on (f.UserID=u.UserID)
and if you are looking for specific user then just add at the end
WHERE u.UserID=#UserID
Looking at you're table structure I think it's best to change the id name in table 1 to *user_id* and add a column in the second table also named *user_id*. Joining using the columns is then very simple using the following query:
SELECT *
FROM table1
JOIN table2 USING (user_id)
Other possibility would be to add a column named *user_id* (or something else) to table2 and create a query like:
SELECT *
FROM table1
JOIN table2 ON table2.user_id = table1.id
In this case, you set the columns to use for the join in the 'ON .. = ..' structure.