I have presented "education" and "experience" as linked to a table "user", but in reality it is a little bit more complex. I have "users" that may contain both "employees" and "employers", than I have tables related to each of them separate, like (I slim down columns for brevity):
I used an artificial key as id, even if the email should be unique. It is preferable this way because I can pass the id as parameter in scripts, so it make things easy. The id is also similar to a SKU for a product, so I guess it is not such a big mistake in this situation.
Does it make any sense to have an userID and an employeeID and employerID? Or even eliminate altogether the userID? I believe I'm fine here...
Contact information, as in your book, are taken out in separate table as a company or an employee may have several contact phone numbers (faxes...etc.). I guess the addresses should have been taken out as one company may have several offices, maybe in the future.
I guess it make sense until now, where I have some doubts is related to assembling together one's CV.
I have things like "experience" and "education" and "driving license", also "personal details" and several others tables for a total of 7 tables. All these should form a regular CV that should be displayed as a whole when an employer is looking to an employee. Now adding to the complexity there are the mentioned "contact/phones" and (eventually) "addresses", another 2 tables. So the total amount of queries will be high as tables like phones, addresses, but also experience, education...etc. have multiple rows of data for one user.
I have some concerns related to performance because there are so many tables and so many queries. Unfortunately this is one person's CV and displaying all data require to collect the data from all tables related to a particular id... it looks to me there is no way around. I would kindly ask you for your best advise.