I have a database that stores username and password. The table is logintable as shown in the picture.
similarly, I have a table called userdetails that stores the details of a particular user as shown here:
Now, using the query select * from .. in postgres, how do I retrieve all the details of a particular user when he signs in with his username and password ? I mean for different user different records needs to be retrieved.
You need a way to join logintable to userdetails. There should be a table that contains both username and firstname/lastname or other way to identify the user in userdetails. If you are making this schema yourself, consider just putting the username in userdetails.
Related
I am confusing about how to design table when have two table reference single column in another table.
For example, I have two type of user ( lets call them user1 and user2 ) because these two type user have multiple different information so I create two table for each of them, and each user have one account to login to system. So I create a table call account and let two table user1 and user2 reference to ID in table account. So when I have one account and I want to know which one this account belong to. It's quite inconvenient because I have to look for in two table.
Does it have solution for this problem ?
If you have an entity user, create just one table user for them.
A user is a user, no matter if he has some special role. There will be some common fields for all users, e.g. a name.
table user:
user id
user name
age
homepage
To have specific information for different types of users, you create specialisation table with information about these roles:
table role1:
user id
roleinfo1
roleinfo2
table role2:
user id
roleinfo3
roleinfo4
roleinfo5
This way, a user can have multiple roles at the same time, but you can of course limit them to just one.
If a user can only be one of those roles (that's called disjunct), you have the additional statndard way to add a column role to your user-table and put all the information side-by-side in the user table, leaving the ones that don't belong to the user-role null:
table user:
user id
user name
age
homepage
roletype
roleinfo1
roleinfo2
roleinfo3
roleinfo4
roleinfo5
Even if the user can belong to multiple classes and in case there is no overlap between the additional columns, you can of course use the last approach and add multiple flags (e.g. columns istype1 and istype2), though this is a non-standard-approach.
Update Just to clarify how you use the first solution: every user has an entry in table user, e.g. with user id = 1. This also makes sure that no user of roles user1 and user2 can have the same user id.
User id in the role tables is both primary key and a foreign key of the user table.
To make that user a user of role 1, you then add an entry to table role 1 with user id = 1. If he is (also) a user of role 2, you add an entry to table role2 with user id = 1.
You can join the tables to get the "whole" picture,
select * from user
left join role1 on user.`user id` = role1.`user id`
left join role2 on user.`user id` = role2.`user id`
This will, apart from the double id columns (that will basically can be treated as the marker istype1, istype2 in the comment to the seconds solution) and the missing role-column look exactly like the second method with just one table.
To check if user with user id = 1 is of role 1, you can check if role1.user id is null in this query, or check if user id = 1 is in table role1. To e.g. list all data for just role 1, you can use
select * from user join role1 on user.`user id` = role1.`user id`
(it uses a join instead of the left join, since and entry for role 1 has to exist).
In most cases you don't even need the specialized data, so you can just join your account-table with the user-table. In any case, you never have to worry about checking two tables (or even more, if you decide to add a 3rd kind of user).
Whats the point of the account table? If each user has one account, why don't you store the account columns in the User table.
Furthermore you can still make a parent user table for the columns they share and then make childtables for the specific users.
for example
Parent: User
Children: Employee/Customer
Let`s say we have the table users. In this table users there are 2 types of users, admin and user. They are linked to an role table through a role_id column but this doesn't matters so much, we can ignore the role table.
An admin has like 5 additional columns for the details and the User has around 25 additional columns for the details.
One option will be to insert all the details columns in the users table, and make them NULL. When inserting a new admin, all the columns for user details will be NULL and when adding a new user all the columns for the admin details will be NULL.
The second option will be to create 2 more tables like users_details and admin_details there will be related to the user_id, and store all the details inside them. And in the users table i will keep only the login info.
Which one you think is the best and why ?
Sorry for the ambiguous title.
I have two tables:
table 1: mailing_email
table 2 (dynamic table but for now is): membership
table 1 contains a list of all email accounts in the database and few ancillary fields such as name. It also has a column called communicate.
communicate is basically my terminology for subscribed. Any unsubscribe link will set communicate to false.
Both mailing_email and membership have a email and communicate column.
I need to write a query where the following happens:
mailing_email.communicate gets updated to the current status of membership.communicate where mailing_email.email = membership.email. If an email exists in mailing_email which does not exist in membership, the communicate field stays the same.
How would i go about doing this the fastest possible way? Each table will have thousands of rows this sync command would run often.
MySQL offers an update join syntax:
UPDATE mailing_email
JOIN membership ON mailing_email.email = membership.email
SET mailing_email.communicate = membership.communicate
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)
It's very simple to someone but looks like complicated to me. I have 2 tables, one is called jos_users other is called jvdb_users. Tables are exact same, both containing user informations such as user email, password, name, etc. Only table one have many users, table two is empty, i need to transfer all fields and data from table one to table two. How do i do that with phpmyadmin and mysql on linux server.
if they both have the same columns you can use this command
INSERT INTO `tabletwo` (SELECT * FROM tableone)
You can write this in the SQL section of phpmyadmin
try this :
INSERT INTO table1 VALUES (SELECT * FROM table2);