Sorry for asking this but I need to know how to do this:
Lets say that a mentor has 10 multiple mentees, is there a way to reduce the amount of fields I need to put in my database (mentee1-mentee10) ?
theres a mentor and student table in my DB
does it has something to do with one-to-many relationships?
sorry if this is too little information im giving, i'd provide more description on what im trying to ask here if you'd like
If a student can have multiple mentors, then you can use a M-N relationship and introduce a 3rd table student_mentor table that will map a student id to a mentor id.
--------------------------
| student_id | mentor_id |
--------------------------
Now, if you need to allow at most 10 mentors, then you'd have to build some triggers that will prevent inserting/updating of records that will violate this restriction.
To conclude, yes, you can reduce the field redundancy, however if you want to keep the 10 mentees constraint you will need to do some extra work.
If you have 2 tables, mentor and mentee, you could give your mentee a mentorId pointing to the mentor table.
And yes - this is very much a one-to-many relationship :)
If however, students can mentor many students AND students can BE mentored by many students, then you have a many-to-many relationship. These are usually modelled by whats called Junction Tables
Related
I'm current developing a professional site for my organization whereby i have the following models:
employee
id
employee_no
full_name
skill
id
name
sector
id
name
field
id
name
sector_id
The relationship are as following:-
Employee has many Skills and also one or many employees can have one skill
Employee can work in different sectors and also one or many employees can work in one sector
Employee can work in different sector fields and also one or many employees can work in one sector field
as you can see the relationship there is many to many between
employee & skill, employee & sector and employee & fields
so i created three tables to handle these relationships the tables are as following:
employe_skill
id
employee_id
skill_id
employe_sector
id
employee_id
sector_id
employee_field
id
employee_id
filed_id
From the above you may see three tables but almost have the similarity. I need help on how to convert this relationship to polymorphic where i can have only one table.
Despite the similarity between skill and sector the model you propose with three joining tables is completely valid. If the entities differs enough in an conceptual level, different models are completely justified.
Would recommend to create an Entity Relationship diagram to pinpoint the consistency of the system.
Here is how to implement those many to many relationships easily in Laravel.
Good luck!
I have users, meetings and comments tables and I want users to be able to post comments on users profile and meetings.
I know how to make one to many relationships for users and comments tables, but I want all comments to be saved in one table and show comments on users profile and meetings.
This is my table structure:
users
id
name
comment_id
meetings
id
name
comments
id
user_id
comment
TL;DR The solution is to use polymorphic relationships which Laravel makes really easy.
IMHO I don't think that a many-to-many relationship will do the job. It would mean that:
a user can post multiple comments. Okay
a comment can belong to multiple user. Weird
a meeting can have multiple comments. Okay
a comment can belong to multiple meetings. Weird
Plus you would likely need two comments tables to achieve that. For instance a comment_user table and a comment_meeting.
The kind of relationship that would fit the most your situation is the polymorphic one. The name can be scary because it comes from ancient greek. But the concept behind the name is very simple. And Laravel makes polymorphic relationships very easy. You will certainly recognize your situation in the example given in the Laravel documentation ;)
While saving comment, also keep a field named model (or anyone you like) to identify users profile and meetings
HTH
I started transforming whole database to a normalised database. But there is one thing which I dont understand about relationships:
Let's say I have 2 tables:
Users
-userID (INT-PK)
-userName (varchar)
_favColor (int)
And:
Colors
-colorID (INT-PK)
-colorName (varchar)
Now obviously I have to create a relationship, the question is:
Should I make relationship between Colors Table and Users Table, or between Users Table and Colors Table?
What I've noticed is that when creating a relationship, the relationship does not appear in both tables, it appears in just one of them, and this makes me confused.
For this example I would recommend a 1:M relationship, going from colours to users.
This is because the users table requires information from the colours table, the reason why you'd have a 1:M relationship is because different users may have the same favourite colour.
I use MySQL and trying to write a PHP script for my school project.
There is one table named lessons contains this columns:
-id
-lessonid.
-studentid
I also have two different tables for notes and announcements
announcements and notes tables contains these columns:
-id
-lessonid
-content
-createdtime
I need to order both announcements and notes from latest to oldest by createdtime but also need to show all lessons a student takes.
For example: A students takes maths and physics lessons. I need to display him/her both notes and announcements for both of physics and maths and all items should be ordered by date. (like a timeline.) And of course I will not show him/her the notes and announcements for chemistry lesson. Also it will be good if I can say it is note or announcement on the list.
Can you help me to write SQL and PHP code for that?
Thanks.
EDIT: This is where I have stuck:
I have combined two tables and ordered them by date. But can't combine them with the lessons a student take.
SELECT title, created, lessonid FROM (SELECT title, created, lessonid FROM notes UNION SELECT title, created, lessonid FROM announcements) as a ORDER BY created DESC
First of all, thanks for letting us know that this is for a school project - therefore I won't give you the answer. If it is in the project then your teacher should have given you the concepts to come up with a solution.
Your question is well put together and I can see how to solve it but ... It's your project so you need to have a crack at it and post what you come up with.
I will give you some hints to get you started.
You need a query to combine the announcements and notes table. Then you need to group the data by the lesson and join that to the students. This is all basic SQL.
Good luck. Post what you come up with.
I'll also, follow fellow posters advice, and not do the legwork for you. but won't let you go empty handed, so will give you the concept.
there is a thing called third normal form, we decide how many tables according to that concept, so if its a big database then separate table for first name and separate for last name, as many people share those among themselves, so saves space and redundancy etc. so one table for person has personid as primary, and has lastname foreign key to refer to last name table , we generally name it lastNameRef, similarly firstNameRef. so now, each person has lot of classes, and each class has lot of persons(students) in it. so this is a many-many relation - we create a allreference table to solve this many to many problem. so there is one table for classes which has class id as primary key, so now u create a all reference table which a recordId as primarykey, (just for namesake) and personRef(refers to personId in person table) and classref(refers to classId in class table) if one person has two classes, another entry with same personId but different class Id, at the end, you can query the name of person from person table, and name of class from class table and create join on their foreign keys but use all three tables, result is (JOHN MATH, JOHN SCIENCE) etc, same way you display all notes for john searching name in person table, and subject in class table,and notes in notes table
Let's say I have 10 books, each book has assigned some categories (ex. :php, programming, cooking, cookies etc).
After storing this data in a DB I want to search the books that match some categories, and also output the matched categories for each pair of books.
What would be the best approach for a fast and easy to code search:
1) Make a column with all categories for each book, the book rows would be unique (categs separated by comma in each row ) -> denormalisation from 1NF
2) Make a column with only 1 category in each row and multiple rows per book
I think it is easier for other queries if I store the categories 1 by 1 (method 2), but harder for that specific type of search. Is this correct?
I am using PHP and MySQL.
PPS : I know multi relational design, I prefer not joining every time the tables. I'm using different connection for some tables but that's not the problem. I'm asking what's the best approach for a db design for this type of search: a user type cooking, cookies, potatoes and I want to output pairs of books that have 1,2 more or all matched categs. I'm looking for a fast query, or php matching technique for this thing... Tell me your pint of view. Hope I'm understood
Use method 2 -- multiple rows per book, storing one category per row. It's the only way to make searching for a given category easy.
This design avoids repeating groups within a column, so it's good for First Normal Form.
But it's not just an academic exercise, it's a practical design that is good for all sorts of things. See my answer to Is storing a comma separated list in a database column really that bad?
What you want to do is have one table for books, one table for categories, and one table for connecting books and categories. Something like this:
books
book_id | title | etc
categories
category_id | title | etc
book_categories
book_id | category_id
This is called a many-to-many relationship. You should probably google it to learn more.
This relationship is a Many-To-Many (a book can have multiple categories and a category can be used in several books).
Then we have the following:
Got it?
=]
I would recommend approach number 2. This is because approach 1 requires a full text search of the category column.
You may have some success by splitting it up into two tables: One table has one line per book and a unique id (call the table books), and the other has one line per book per category and references the book id from the first table (call the table bookcategories). Then if you only need book data you use table books, where if you need categories you join both tables.