I'm storing job profiles in my db kinda like Linkedin does.
you can sign up as a candidate or as a company but now i have only one table
user_tb
where user_tb.user_type is the tag to identify a candidate user vs a member/visitor, vs. a company
Imagine if i wanted the users to be able to add their own employees of that company.
where the employees should be stored? I'd store them in the main user_tb right?
so what about companies? and if i store employees in the same user_tb their email cannot be empty... how can i fill emails if i don't have them?
shoudl be user_tb a separate table from employees?
I would create a separate table for companies and users, and then have a column on the users table for their company id to link them together. It gets too messy when you try to cram everything together into one table.
If the users table requires an email, and you're wanting a place for companies to add employees, you can require them to give the employees email, or create a separate table for employees that doesn't require an email, but can be checked before signing up a new user to see if they already exist in the "employees" table.
Related
In an application I've been building, I have a users table. The users represent a firm's staff. I also implemented a role/permission system. Permissions are assigned to roles (staff, manager, director, etc.), and roles are assigned to users. Permissions prohibit the use of certain actions in the app.
Now, I'm introducing another user type: customer (will also be able to log into the app). The customer fields are different from the user fields, so I can't store the customer information in users table (and create a role for customers).
(Normally, just creating a customer role for the customers and store the custumers in the users table would be fine, but since the fields are different, I don't think that's an option.)
First, I thought about creating a seperate table for the customers, but I'm not sure if that's okay, because when someone tries to log into the app, I have to check two tables (users and customers) for the log-in credentials. What if I introduce a third user type? Check three tables? That doesn't seem practical/efficient.
So I thought about seperating the log-in credentials from users, and ended up with three tables:
users will hold log-in credentials
staff will hold staff meta/profile information
customers will hold customer information (same as staff)
This way, I can introduce many different types of users. And if I know what I'm looking for, I can get the record. For example, say I want to get/query a staff, I can just do:
SELECT * FROM staff
JOIN users USING (user_id);
The problem is how do I query users when I don't know what I'm looking for? I mean, the logged user can be a staff, customer, etc. I need to do something like this:
SELECT * FROM users
JOIN [specific_table_name] USING (user_id);
How do I know which type of user just logged in? I could store the user type (the target table name?) in users, but will it help in a (single) query? I mean, find the user in users (using credentials), and then join the user information from another table (staff, customers, etc.)?
Currently, I'm thinking about doing two queries. First is to get the user (credential) record, and the second is to get user (say, profile) information (using a field type from user record).
Of course I'll be doing this in PHP. For example (not real code):
$email = "someone#example.com";
$user = get_user($email); // SELECT * FROM users WHERE email = "someone#example.com"
switch ($user["type"]) {
case "staff":
$user = get_staff($email); // SELECT * FROM staff JOIN users USING (user_id) WHERE email = "someone#example.com"
break;
case "customer":
$user = get_customer($email);
break;
// ...
}
// how it's done doesn't really matter. the thing is "type" needs to be checked to get the corresponding user info
Is this best way to handle this? Is there a way to make the queries in SQL (without resorting to PHP)? Like JOIN after WHERE? Or make two queries in one (save the first query result, and use a column value from the first result as a table name in the second query)?
Mentioned tables:
I'm still researching, and I found out that what I'm doing with the tables is called (?) "Class Table Inheritance". It seems clever for non-login related entities (when going from child to parent; e.g. staff -> user), but in reverse (parent to child, e.g. user -> staff|customer|etc.), it seems problematic. Since I figure these things as I go, I'm stuck at the moment.
One solution that just (while typing) occured to me is to use different log-in forms/pages specific to user types. The form/page could let me know the user type beforehand, but I rather not use this method. So, single log-in form for all users.
I'm calling users as the base/parent table, and the stuff, customers, etc. as the child tables, because first insert happens at users, and child tables use user_id from users.
You could create a union and use an alias in the query to define different fields mapping for the same name, if there is no field in one table you just cast the alias for an empty field:
SELECT (staff.name) as name FROM users
left JOIN staff USING (user_id)
UNION
SELECT (customers.first_name) as name FROM users
left JOIN customers USING (user_id);
If the userId is a PK/FK it will be only returned by one table.
I would set all users login info and email to the parent table (customers and staff) and two tables with foreign id key for other data, with users.type as you suggested. It could be done with one query, too and Switch condition is not needed:
SELECT users.email,users.type,staff.field2,customers.field3 from users
LEFT JOIN staff ON(users.type='staff' and users.id=staff.uid)
LEFT JOIN customers ON(users.type='customers' AND users.id=customers.uid);
I created Users table.
After the user registered, The system enter his address, phone, city and more personal details to Users table.
There is another table, called Contacts, there the user add another people details.
Now, if there is Contacts table, How better to save the personal details of the user in Users table? in one json column that contains all the user personal details, or in normal columns (address, phone, city)?
I just do not want to happen a situation of multiple data.
I think separate columns for each field will be the better option!
Well, it would of course be easy to just store it as JSON, but that way, it could be a bit messy to search for certain stuff in the database (say you wish to check all users from a given city for example).
When it comes to user information, I always find the best way to do this is to store only login vital data and the base info in a users table.
Something like:
id | email | password
And then have different tables for the other data.
Name and such (which a user only has one of (of course one could have multiple names, but I usually only store first and last names)) could be stored in a user_information table, which is in a one to one relation with the user (foreign key for the user_id so that it can be quickly fetched when needed).
When it comes to address and phone number, a user could actually have multiple.
I understand that its possible that your system/app is only supposed to support one address or one phone number and the like, but its always nice to make it "right" from the start, so that its easy to just let the user add multiple of them whenever the need is there.
That way, you would have a few different tables:
users
user_information
addresses
phone_numbers
and so on...
The user_information, addresses and phone_numbers would preferably all have a user_id column which would be used for a foreign key to point at the user who owns it. And if you wish to make it possible to use the same tables for contacts, a contact_id could be added too (and a foreign key to point to the contact).
I'm looking for guidance on the database structure for a multi-regional website.
I am setting up a website, similar to craigslist.com, that will allow users to post adds in their city. I am using a MySQL database.
I want to have regions as subfolders linked to subdomains e.g. ca.mysite.com goes to mysite.com/ca.
My question is how do I manage the database(s) when I want to add another city to my website.
If I use a different database for each city, then users wont be able to login to other cities as their login details are stored in the city they registered at in the users table of it's db.
This may not be an issue though, as the content is city specific, like craigslist.
But, should they wish to contact users in other cities, they wont be able to.
Also, there would be duplicate username's and email addresses overall, as users could register in all of the cities using the same email and username.
If I create a central database with for instance, a users table, and a messages table, and then a separate db for each city with all that cities 'posts' then when displaying basic information I will need to consult the city specific db plus the central db that stores user info.
Alternatively I could store everything on one database, and store the logged-in user's location in a cookie, pass that to a session variable, and use that location as part of the database query when displaying search results etc.
However, would this not add an unnecessary overhead to each query?
e.g. every search would have to have ' AND location = $user_location ' added in.
I really have no idea what would be the best method here.
Thanks in advance for any help on this.
It seems that you still do not know clearly the system you want to build. Before starting designing a database for this system, please make sure that you have the full description of the system requirements. Some sample questions that help you clarify are:
What features does your website offer?
What are all the actions that a user using your system can do? With each action, is there any restrictions?
Some other questions relating to the system performance:
- How many users do you expect to use your system?
- How fast and correct each action should be served? Which actions are used frequently?
It makes no sense to design a system without a careful understanding about the system requirements.
So here is the sample database design and how it can support your requirements.
Cities(cityid, cname)
Users(userid, fname, lname, cityid, currcityid)
Messages(mid, senderid, receiverid, content)
Adverts(aid, title, content, userid, cityid)
When a user switches the city, update the currcityid field in its row in the Users table.
When a user posts an ad on a city, insert a new row to the Adverts table. The userid and cityid of the new row are the ids of the corresponding user and city.
When a user sends a message to another user in the system, add a row to the Messages table. The senderid and the receiverid of the new row are the ids of the corresponding users.
Query all ads in a city: SELECT * FROM Adverts WHERE cityid = $cityid
Query all ads of a user: SELECT * FROM Adverts WHERE userid = $userid
Query all ads of a user in a specific city: SELECT * FROM Adverts WHERE cityid = $cityid AND userid = $userid
Hope this helps.
i have three tables to store details of different types of uses: customers, suppliers, staff
here are the structures of them,
customer(id,f_name,....)
supplier(id, name, address....)
employee(id, name, job_title....)
now i need those to log-in to the system , the log-in details stored in separate table,
user(user_id, password, role, ref_id)
how i planed to work this is, when registering some one, firstly insert the record to customer, supplier or employee according to the person, then insert a record in to the USER table in which the "ref_id" is the id of the previous table. the user is provided the "user_id" which can not be changed and they can change their password themselves.
when log-in, check the user_id, password combination, if ok then takes the ref_id and type, the appropriate table can be determined by the type which may be customer, supplier or employee....
the reason i done this in above way is,
customer, supplier and employee table has many different attributes except few like id, name...so can not maintain all the data in one table. in this situation if we use ids of customer, supplier and employee..would provide duplicate ids because they are separate tables!
so i need to know,
Is it correct the way i have implemented the authentication ?
if it isn't what is the correct way? (please mentioned that the details of the three parties should be handled separately)
i need to define relationship between supplier, customer, employee --> with user table. so is it ok to define three relationship as follows or another solution, how if the user table keep alone without relationship? is it violate the relational database concept?
customer (id-pk) ---->user (ref_id-fk)
supplier (id-pk) ---->user (ref_id-fk)
employee (id-pk) ---->user (ref_id-fk)
I'm building a school project and my idea is to have a site where you can register an account, add a couple of users to that account and then calculate their monthly shared expense debt, e.g. User A pays 500 on groceries and user B only pays 250. This gives User B a debt of 125 to user A that month.
My problem is that I want to separate the accounts with the users. Now I have a setup of a table called Accounts with email and password and then I have a users table with particular user information. I want several people to be able to log in to the same account using different credentials.
Users table
ID, Name, Account_id etc.
Accounts table
ID, Email, Password, date_added, date_updated etc.
What is the best approach of doing this? Is it to have a cross-table called UsersForAccounts or do I specify several account_ids in the Users-table?
You wouldn't think of it as several users on one account. You would think of it as several user accounts that share a common group setting.
So you have a user's table as you may expect - each with its own values for that person, obviously.
Then you have a related table that shares the details for the group. Let's use a fraternity or something as an example.
SO you have Pi Phi as a group name. Within that are Users A, B and C.
A very very basic table structure might look like this:
Users: id, email, password, name, group_id
Group: id, name
So a user would - by this setup - have a relation to only one group. You could make that a relational table so a user can have many groups if you want.
The general idea here is that you use the group as a separate connection point to the user and not necessarily several users that access with the same account.
If that is unclear, feel free to ask and I may update
You can use a structure such as in the Users Table:
ID, Name, etc.
And in the Accounts table use simplest:
ID, Email, Password, date_added, date_updated, User_ID, etc
This is called Many to One relationship, and is ideal to your case.
A small tip i can pass to you is use LOWERCASE to ALL your fields, or in special to the first character of the name of the field, with an excerpt for "ID" (that is only a acronym (or similar) to Identification)
In an basic example, the Users table has the fields:
ID, name, etc.
And Accounts table the structure above:
ID, email, password, date_added, date_updated, user_id
This can't help much in a short time, but it can help you, and very much, at use of the database with PHP.