I have a corporate website which is used to communicate between staff members as well as staff members with clients. There are internal users who can login and work with their mail using web interface, there is a list of external clients with email address and phone numbers which internal users can use to write an email or make a call. Sometimes clients become staff members, sometime staff members gets fired but stays in the database as they can become future clients.
There are two MySQL tables for those two types. First one is a full list of all people, and there is a separate table of internal users partially duplicating the first table. The second table for the people who can login so it has login, password and some permisisons fields but it also have last name, first name, job, address etc. which is already in the first table.
So all internal users have two entries - one entry at the users table and one at people table. People table has internal users and all the external clients data.
I'm thinking to make one table from those two just by adding internal users fields to the people table such as login, password, permissions etc. so whoever have those fields filled considered to be internal users. That would probably simplify my SQL queries and get rid of edless SQL JOIN constructions as I constantly have to fetch data from both of the tables in order to get full data on a user.
Basically I want users table to become part of the people table. Is there any negative consequences per your experience may be in terms of security or conviniency that can be a problem for such an integration of clients and users being put together in one table?
I don't think you should get rid of the users table. The distinction between internal and external users is too important to depend just on the use of columns.
Instead, make users a "subtype" of people. So keep the people table and include all the users in them, with the appropriate "people" fields. Then in your users table, include the internal information along with a people id.
With this structure, it is easy to get "everyone" (from people) and "internal users" (from users). To get external users, you need to do something like:
select p.*
from people p
where not exists (select 1 from users u where p.personid = u.personid);
This should be a fast operation, with a index on personid. You could maintain a flag in the people table, indicating whether someone is or is not a person, but you would need a trigger to keep it up-to-date. Probably not worth the effort.
Related
I know that there is not a "good" answer to my question, and it is opinion based. But since I am now learning those things on my own, I need advice.
I have a table on Mysql about "Customer". In this table there are columns referred to customer's info like name, surname, date of birth, address, and so on.
Each customer has his own credentials (username, password).
Now my question is: It is better to keep credentials in "customer" table, or it has sense to create a separate table, in order to guarantee the protection of these credentials, and also keep track of the changes of them along time, without wasting space repeating all the others customers' info?
You need to answer some questions about your data:
Do the columns change? People change names, addresses, and so on.
The credentials will change, at least the password.
What sort of history do you need?
My recommendation would be different sets of tables for different purposes:
One table that defines the customer id and whatever other immutable information there is (perhaps the date of becoming a customer and related information).
One or more tables with PII (personally identifiable information). You want to keep PII separate for regulatory and privacy reasons.
Tables for history. How you do this depends on your data model and what you need. A simple method is a single archive table per table in your data model. However, I might recommend type-2 tables (i.e. those having version effective and end dates).
Separate tables for credentials. These are even more sensitive than PII and you will want to control access.
Remember to never store clear-text passwords. And often you want to keep a history of passwords to prevent users from using the previous one.
It is better to create personal information in the person table and additional customer information in another table that has a relationship with the customer, and if you have any other information about the person in another table and link it to the table of persons.
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'm developing an e-commerce site and I wanted to get this community's thoughts on a database structure for groups, users, and their memberships.
THE GOAL: Determine a user's group membership(s) and access privilege at login. A user could be a seller on this site, an admin, a site support, or ANYTHING. Must be scalable.
INITIAL THOUGHT: Three separate tables: users, groups, and memberships. At a successful login, search the membership table for the user's ID and get group ID's from that same row in the membership table. From there, another query to get group information from the groups table (like name of group, description, etc). Store the memberships in the user's session and call it a day.
THE CONCERN: At log in, I don't want to unnecessarily perform additional queries. The above "initial thought" consists of 3 separate queries at login.
THE QUESTIONS:
Is this the right approach?
Any better design solution(s)?
Better to break admins into their own table, or toss 'em into the same groups table?
The database design is reasonable. As a user can belong to multiple groups and can have multiple memberships, two additional tables USER_GROUP and USER_MEMBERSHIPto hold the relations between users and groups and between users and memberships will be necessary.
I am trying to model as much of the data as possible for a new app before starting. The app will have Users & Spaces. The Spaces will have a number of Admin levels but will also have non-admin Members. The Space will associate Admins through space_roles/space_admins join table (name depends on the design decision I am trying to make). I am using a Role model to create the association between Spaces and Admins. This means the the space_roles table will be a three way join with user_id, space_id and role_id columns.
I plan to eventually build a bunch of tools around Spaces that the Members will have access to. These might not necessarily be restricted to Members of a certain Space. There most likely will be cases further down the road where Members of one Space can interact across organizational boundaries with Members of another Space using the Space as the scope (e.g. a fan of one sports team could join in on a discussion on the wall of another sports team where sports team is an analogy for Space).
My question is should I just create another Role called 'member' or should I break members out into another model (Member?) with an association through space_members? Please explain the advantages/disadvantages of your recommendation as best as possible.
If your Admin users are a subset of your Users, and it's possible for Users to become, or stop being, Admins, then keep them in the same table.
If your users (admins or not) can participate in more than one of your spaces, you probably want a single users table, and a separate users_spaces join table. That table might have this layout.
user_id part of the primary key
space_id the rest of the primary key
role 1 = contributor to the space, 2=member, 3=admin 4=owner etc
If users and admins are entirely distinct sets of people, then use two two tables and keep them separate. For example, if you were doing health care, and they were Nurses and Patients, you would definitely keep them separate, because they are subject to different confidentiality rules.
I'm having a bit of trouble figuring out how to structure my database for an application I'm building.
There will be three different types of users:
Admin
Applicants
Reviewers
I'm planning on having a general users table to store shared information between each user type. However, I'll need to store quite a bit of information for Applicants that I won't for Reviewers, or Admins, and I'll need to store some permissions information for Reviewers that I won't for Applicants.
I know I'll need to set up some additional tables to accommodate this information but I'm not sure how to do so. Should my users table have an admin_data, reviewer_data, applic_data fields as FKs? How would I detect what type of a user a person is when they login?
Each user will only need to be one type.
Thank you for your help.
Have an accounts table with login info, account id and account type. Then join to the appropriate related table (admin, reviewer, etc) to get relevant info.
There's no reason to mix the data since it sounds like it varies quite a bit.