I am newly responsible for a database.
It contains the tables "users", "role" and "users_roles".
In "users_roles", "uid" (user id) from "users" and "rid" (role id) from "role" are mapped, as the former administrator told me.
WHAT I NEED TO DO:
I need to create a form by which users can register. Every newly registered user needs to appear in the table "users" of course and at the same time he must be attributed the role "7" and his "uid" must appear together with "rid" = 7 in the table "users_roles".
QUESTION:
I already know how to add the user to the "users" table. But how do I achieve, that his user id is mapped to the role id = 7 and that this entry appears in the table "users_roles"? Which SQL query do I need to write? $db->query(' ????????? ')
Regarding, "But how do I achieve, that his user id is mapped to the role id = 7 and that this entry appears in the table "users_roles"? "
There is always more than one way to do something. In this case, I would make 7 the default value of the role_id column in the users_roles table. That would make providing a role_id optional as you add new records.
Related
So I want to make a webapp that needs to store the following.
"Users"
some "Events"
and some "Customers"
each "Event" has a "User" which is represented by a userId column.
But each "Event" can have multiple customers, to be able to store all this info,
I thought it's better to have a new table "Customers_In_Events" that has 3 columns:
id, -- Not sure if that's needed
e_id -- Event ID
c_id -- Customer ID
I have 2 questions...
Is there some better way to do this?
If I decide to go with the way I mentioned (an extra table), Would the "id" column be needed?
I am using MySQL by the way.
You can use a bridge model to represent your data, which is also normalized.
every event can have multiple customers
every customer can have multiple events
so the tabkes would look like
Events events_coustmers cutonuers
e_id(PK) e_id(fk) c_id(Pk)
e_name c_id(fk) c_name
PK(e_id,c_id)
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
I'm creating a website and users can add friends. I want them to be able to see their personal friends on a page.
For exemple:
John add user Tim and Bill.
When John goes on his friends list page, I want him to be able to see that he has Tim and Bill. How do I do that? Is that even possible? Do I need more than one table? If so, does every user has to have his own friendsList table?
Yes this is possible, you do this by querying the information from the database, the answer for if you need multiple tables etc all depends on your current table structure but at the very least you need to have some way of referencing that a Person 'John' has friends, wether thats just a 'friendID' in the same 'Person' table, or another means of doing so. then it is just a matter of querying the data correctly to return what you want and bind to the websites fields :D
One way of defining the structure is the following:
Person
PersonId
Name
<other person fields>
Relationship
RelationshipId
Name --> allow to define multiple relation types like Friendship, Follows etc.
Relationship
RelationshipId
Person1Id --> FK to Person
Person2Id --> FK to Person
RelationshipTypeId --> FK Relationship
Basically, you use an n:n between Persons (anyone can have any number of friends) and also allow for other types of relationships.
Assuming you already have a table of users, one approach would be to create a "friends" table which relates users to other users.
CREATE TABLE friends (
`user_id` INT NOT NULL,
`friend_id` INT NOT NULL
);
Both user_id and friend_id would have foreign key constraints on your existing users table (so that you guarantee an id must exist in your user table in order for it to exist in the friends table as either a user_id or friend_id).
You can then link your user table on users.id = friends.friend_id to get the friend's info.
Here is a SQL Fiddle Demo showing how this works.
You should consider using an ON DELETE CASCADE constraint on the friends table, so that if a user is deleted from the user table, the associated records in the friends table are also deleted.
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 ?
In my Users table I have a row called "products_in_sale" that contains the product ids of the products the user sells.
For one user it looks like this. "33" <-- therefore this very user sells only one product with the id 33.
Now, since users can sell more than one product, I have to join another number (preferably with a "," in between) to this field when a user creates a new product.
How does the necessary UPDATE statement have to look?
maybe 'UPDATE Users SET products_in_sale = products_in_sale + ", '.$id.'"'; ?
thanks for your help!
Use the CONCAT_WS function:
UPDATE Users SET products_in_sale = CONCAT_WS(',', products_in_sale, newProductId) where userId = ?
This query should work also for the first insert, if your products_in_sale column defaults to NULL.
Anyway, as suggested by juergen, using another table would be a better option.
Never never store multiple values in a single cell, this is a violation of first normal form (1NF). Read more: http://www.ntu.edu.sg/home/ehchua/programming/sql/Relational_Database_Design.html
Every value (e.g. product_id) should have its cell in a relational database table. In your case, there should be a table say "user_product" with at least 2 fields - "user_id" and "product_id", and both are composite primary key.
Of course, there should be a "user" table storing user details which would have a "user_id" field linking to the "user_id" field of the "user_product" table. Likewise, there should be a "product" table storing product details which would have a "product_id" field linking to the "product_id" field of the "user_product" table.