I am trying to register some users with basic details like username/email, password and their respective hobbies like reading, sports, dance etc and later on display users with similar hobbies. The current schema looks something like this.
Users
- id
- email
- password
- country
- hobbies_id
hobbies
- id
- user_id
- sports(values true/false)
- reading(values true/false)
- dance(values true/false)
Each hobby is placed as a column in hobbies table.
What will be the most optimized schema if I increase the number of hobbies from 3 to 20?
Also, can someone help me with a query to select users with similar hobbies/hobby? For example, if John likes reading and sports, and Kim likes sports and dance then they have sports as a common hobby.
Thanks in advance.
Following up on comments by #Madhur Bhaiya, I would adress this with 3 tables:
users
- id
- email
- password
- country
hobbies
- id
- name (sports, reading, dance, ...)
user_hobbies
- user_id
- hobbie_id
The users table is the master table for users (one record per user).
The hobbies table is the master table for hobbies (one record per hobby). When new hobbies are created, you do not need to create new columns, just add new rows.
The user_hobbies table maps users to hobbies: it contains one record for each user_id/hobbie_id tuple.
we can do with two solution ::
#GMB's solution
removed hobby table and save hobby data into user table only, in json data-type.
For this, I would recommend looking into Database Normalization. This issue should be solved by implementing the Third Normal Form (TNF). For this, you should remove hobby_id from the users table and remove user_id from the hobbies table. A normalized example of one solution to this problem would be to create a new table that uses user_id and hobby_id as a Composite Key. See below:
users:
- id
- email
- password
- country
user_hobby:
- user_id
- hobby_id
hobbies:
- id
- description
- type
In this situation, the user_hobby table would have a many to many relationship between users and hobbies. If a user has multiple hobbies, they will have multiple hobbies linked to their id in the user_hobby table, but each user and hobby should be listed only once in their respective tables.
Related
I have 3 entities: Tutors, Students, Courses
Tutors teach many courses
Students can be assigned to many courses that are taught by many tutors
Tutors and students need to be able to log into the system
I would like to represent this design using the following tables:
users
- id
- username
- password
- first_name
- last_name
- email
- password
- phone
- role_id (Student or Tutor or Admin)
- created
- modified
roles (Student, Tutor)
- id
- name
- created
- modified
courses (The courses that Tutors can teach and that Students can be assigned to)
- id
- name
- created
- modified
users_courses
- id
- user_id
- course_id
- created
- modified
The problem I have with the above design (users_courses table) is that, let's say we have Tutor A and Tutor B that teach Math. If student X is registered to that math course we can't know if student X is being tutored by Tutor A or Tutor B.
I would really like to be able to use a single users table to keep all the users to make things simple.
Any advice please?
The problem is that you want to handle students and teachers differently (students enroll in a course taught by a specific teacher) but you modeled them the same (they're just users).
Instead of roles, create subtypes of users. Create tables for teachers and students - you can reuse the primary keys from users, but you'll be able to handle subtype-specific attributes and relationships.
While it's possible to get away with only those entity sets, I suggest you add the concept of a section as well. It has different names in different systems or parts of the world, but most school systems I've seen have something like it to represent a partition of a course's students with an associated teacher.
users
- id PK
- username
- password
- first_name
- last_name
- email
- password
- phone
- created
- modified
students
- user_id PK FK
teachers
- user_id PK FK
courses
- id PK
- name
- created
- modified
sections
- section_id PK
- teacher_id FK
- course_id FK
- created
- modified
students_sections
- student_id PK FK
- section_id PK FK
- created
- modified
In a real world system, you'll also need to take time into account - students and teachers normally attend different courses in different years or semesters.
I would simply add the “tutor” to the courses table since it’s essential element for a course to know whose is teaching it/tutor.
Then use either the users table or user_courses to join/match and pull the info you want.
**Courses**
- id
- name
-tutorID
- created
- modified
i have 2 type of users
1. employee.
2. employees friend.
both users have common fields.
1.first name
2.middle name
3.surname
4.cellphone number
5.telephone number
6.city address
7.email (serve as login)
8.password
9.registration date
10. update account date
and the employee friend user don't have this field
1.employee id
2.company name.
3.company branch
4.position
and they will be going to use same login form.
edited version (thanks to nawfal and Patrick James McDougle)
1st table (user) should contain field 1-10(first list) and a new field fk_employees (foreign key to our 2nd table, null if it is an employees_friend)
2nd table (employees) should contain field 1-4(second list)
I think about this the same way I think about object oriented programming. If employee EXTENDS user then employee should be a user with extra information. I would have two tables.
Users (containing the common fields adding an id field perhaps)
&
Employees (with the 4 extra fields for employees and one field that references a unique identifier in the users table.)
More information about what I am proposing can be found here: http://www.agiledata.org/essays/mappingObjects.html#MappingInheritance
what i suggest create 2 separate tables as users and user_friends with the fields mentioned above.
Now create a view with following query:
select employeeID,email,password from users
union
select friendID,email,password from user_friends
Query this view to get the login info in your application.
I am creating a site where each registered user can store a list of contacts. It occurred to me that rather than storing the contacts in a table with user_id, contact_name, contact_email, it would be better to normalize it to prevent the same names/emails being stored multiple times. As a result, I now have 4 tables: users, names, emails and contacts where contacts contains user_id, name_id and email_id. Am I heading in the right direction, or am I complicating things needlessly?
Thanks for all the helpful responses to what I can see now is a pretty nebulous question. It may be a good idea to explain my reasoning.
In an example scenario, where there are 100 users, most of whom have joined though the recommendation of another user, there will be a large number of common email addresses shared by each users contact lists. However, johnsmith#email.com, may be known as John, J Smith, Johnny boy etc. by different users. If I understand the principles of normalization correctly (unlikely) the separation of user, contact name, and email address in to separate tables, should reduce duplicate entries significantly and make the database more efficient. In the example below, the Contacts table could contain the same email addresses multiple times.
So, to cut a long story short, is it better to have more entries than necessary in one table or several smaller tables without duplicate entries?
You're probably needlessly complicating things: I'd recommend one table for users, one for contacts and a join table to allow a many to many relationship between the two. If contacts are not shared between users it'd be acceptable to have the user id as a foreign key in the contacts table.
Hope this helps
You can do like this
1] User_info Table
User_Id | name
2] Contacts Table
Contact_Id | Contact_Name | Contact_Email
3] User_Contact Table
User_Id | Contact_Id
Can contacts have same email but distinct names, or vice-versa ? If not, i suggest two tables (users and contacts) linked by an associative table :
USERS
- userId
- userName
CONTACTS_USERS
- userId
- contactId
CONTACTS
- contactId
- contactName
- contactEmail
With foreign key constraints on userId and contactId you can achieve a robust linkage between the two tables, where each contact may be used by distinct users and where each user may have distinct contacts.
I have a list of checkboxes in my form, user may chose any of them, or just all of them.
Think that user selects the type of sport he is interested.
I need the best database structure to store this user choise. So that, in future I can get all this data.
I think, I just can store each (userID, sport) choise as a new row in database table. But it is confusing me, because table will expand faster with just a few number of users.
Any ideas, brothers?
You can setup a many-to-many table such as:
FavoriteSports
------
id user_id sport_id
1 5 20
Where you have:
User
-------
id name
5 Mike
Sport
-----
id name
20 Football
This makes sense because a user has many sports, and a sport has many users.
Deciding how to do this is called normalizing.
There are multiple ways to do this depending on how normalized you want your data.
The simplest way is what you described.
userID userName sport
Or you can have 2 tables
users
userID userName sportID
sports
sportID sport
Or you can have 3 tables
users
userID sportName
sports
sportID sportName
user_sports
userID sportID
Where the user_sports table contains which user likes which sport.
Which method you chose depends on the relationships of your data and how much duplication you expect.
If you are only storing which sport a user has chosen, I would choose the second one. That prevents duplication of sport names but only allows one sport per user. If you want to allow users to choose multiple sports, use the third option.
I want to create a database that can store the friends contact list as like social networking
what is the best way to design the database structure and easy to retrieve the contacts of friends using mysql.
I need solution for this, HELP ME
The best way to model heriarchical data depends on what operations you need to support. I would suggest that you read Bill Karwin's slides Models for heirarchical data for a comparison. See in particular slide 48 where there is a summary of the strengths and weaknesses of each approach.
However, I wouldn't regard friendship as a heirarchical structure. There will normally be loops: A is friends with B, B is friends with C, and C is friends with A. Instead you can create a contact table with two columns: user_id and friend_id which are foreign keys into the "users" table:
contact_list
------------------
user_id friend_id
------------------
1 2
2 3
3 1
To retrieve the contact list for a specific user id run this query:
SELECT friend_id
FROM contact_list
WHERE user_id = 1
Here I'm assuming that A being on B's contact list does not imply that B is also on A's contact list.