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.
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 2 tables namely users and employers . I would like to match them together like tinder style, which means that when both the user and the employer liked each other , they will each receive a notification .
However i am not sure how would the relationship table will look like??
Right now what i have is in the Relationship Table ,
1.user_id
2.target_employer_id
3.employer_id
4.target_user_id
If i am not wrong , this is considered as a Many - Many relationship.
So , is this table correct???
As I understand your question, in your application, a user can like an employer, and an employer can like a user.
If this is right, it seems clear to me that there are two distinct (many to many) relationships (user => employer, employer => user), and that in your proposed table only two fields are filled at a time.
The best way to represent those relationships is to use two tables.
User to employer fields:
user_id
target_employer_id
Employer to user fields:
employer_id
target_user_id
Depending if you are using Laravel 4 or Laravel 5, you can use one of those two packages to generate the two pivot tables via a migration:
https://github.com/JeffreyWay/Laravel-4-Generators
https://github.com/laracasts/Laravel-5-Generators-Extended
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
I am trying to model a database for my current project and I came across a new problem. I have a Project which is supervised by Supervisor, Coordinator and Company. So Project table has Supervisor.id as foreign key and so on. There is also Student table which contains Project.is as a foreign key (because many users can do a project). This is how it is right now. What I would like to do is to have a User table containing a column named type which allows me to see what the role of that particular user is (also student). Even though the table will contain many NULL entries, I will have far less redundant code.
However, the main reason I want to have one User table is that I am using CakePHP and it is not easy to have different models log in. Is this possible in a nice way?
Thanks
EDIT: Maybe I should say that every one of these roles will have different permissions.
I see three tables: USER, GROUP, and ROLE.
Users would be assigned to groups, and groups given roles. I think you need three, not one.
And cardinality matters: I can see where a USER could be assigned to many GROUPS; a GROUP could have many USERS; a ROLE could be assigned to several GROUPS; and a GROUP could have many ROLES. There are many to many JOIN tables as well:
USER <-> USER_GROUP <-> GROUP <-> GROUP_ROLE <-> ROLE
This is normalized - nothing is repeated this way. USER, GROUP, and ROLE have primary keys. The JOIN table primary key is a composite of the two IDs in each row.
It depend on how you will use your associations.
Why not
For example: if you use relation to output data later and you sure, that you database scheme will not changed, than ... why not? your main targets: quality of code and speed of development, so, not matter how much columns with null you will have.
But
if you not sure in your requirements or plan to extend database scheme you can use two columns
supervisor_model
supervisor_id
which will store apropriate values: Company, 77 (I mean that 77 it's id of come Company )
Another approach
You can UUID for you supervisor_id so, it will be unique among several tables and you have not many NULL and extra columns.
I have 3 tables,
users(id) , userproduct (user_id,product_id) and product (id).
When a user adds a product their user_id and the product_id is saved in USERPRODUCT table.
Now at the same time another user can save a product (kind of like "set as favorite") for this I need to save the user_id of the user who saved it and the product_id of the product. This will create another table (call it favorites) however this table is also a resolve to the many to many relationship between "users" table and "product" table.
the question: is it possible for this, to have 2 tables resolving a many to many relationship or is there any other way to solve my issue.
if it is possible how will one be draw this in the ER diagram
it depends on what you want.
you may use only one table and design your relations with boolean fields
USERS(id)
PRODUCTS(id)
USERPROD(userid, productid, isbought, isfavorite, isowned)
or you may use one many-to-many support table for every relation is up to you
maybe you want another field "owner" in PRODUCTS table to store the user id. this is a one-to-one relation
What you want to do is actually describe the kind of relation between user and product: a favorite, or he 'owns' it.
Just add another field to the userproduct-table defining the relation: favorite or owned