In my db I have three tables (I have more but for case is equal, users can be companies or single people).
Users
has a primary keyid_user
;Company
has a primary keyid_company
and a foreign keyusers_id_user
;job_offers
has a primary keyid_job_offers
and two foreign keys:company_id_company
andcompany_users_id_user
.
My questions are:
- Does a primary key make sense in
job_offers
? I don't think that there is a reason for it. job_offers
has two foreign keys, one related tocompany
and 开发者_如何学Pythonother tousers
. Is there a problem with this? Does there exist another way to accomplish the same task?
All tables should have a primary key. It sounds like you are asking whether your primary key should be a surrogate key or a natural key.
You might ask the same question of your other tables as well. For instance, assuming the email column in your users table is required and unique, it could be used as a (natural) primary key.
This question is pretty heavily debated, and both approaches can work (as can a mixed approach). If you want to read up on this subject in general, do a google search for "Natural vs. Surrogate Key".
Does a primary key make sense in job_offers? I don't think that there is a reason for it.
Yes . I agree that every table should have their own PK. Should each and every table have a primary key?
I have more but for case is equal, users can be companies or single people
job_offers has two foreign keys, one related to company and other to users. Is there a problem with this? Does there exist another way to accomplish the same task?
The system have two types of users: normal user (person) and company user. The job_offers is a table that save job offers from a company. If a company user want to post a job , a record will be inserted to the job_offers table . Then once the normal user get this job offer , the job_offers.company_user_id_user will be assigned to this normal user 's userid.
But from your ER diagram , Company.users_id_user
is the PK , which cannot be null , and this PK is used in the job_offers.company_users_id_user
as a FK. So job_offers.company_users_id_user
also cannot be null .
As a result , it cannot handle the situation that a company user just post a job and before a normal user gets this job offer or no one gets this job offer eventually .In this case, job_offers.company_users_id_user
should set to null , which violates the job_offers.company_users_id_user
's not null constraint.
I will accomplish the same task using this design:
Users
=================
id_user (PK)
email
activation
password
Company
=================
id_company (PK)
activities
foundation
user_id (FK to Users)
description
job_offer
=================
id_job_offer (PK)
id_company (FK to Company)
description_offer
tags
user_offer
=================
id (PK)
user_id (FK to Users)
job_offer_id (FK to job_offer)
1) make sense a primary key in job_offers? I think there is no reason
Yes there is - every table ought to have a primary key. It's called 'normalization.'
Your choice might not be very good. I'd say that the two foreign keys together should be the primary key, not the id column.
2) The job offers have two foreign keys, one related to company and other to users, any problem ? exists another way (best way) to make this?
No, that's how many-to-many relationships are done.
- I think you're right. There is no need for a separate
id
field there. The two foreign keys should, together, make up the table's primary key. - Looks fine to me.
精彩评论