I’m doing a database design for user experience with specialties. A user can have experience months/ years for each specialty ( please see the attached images)
I’m planning to create a table to list all specialities, and a table to list experiences within years, and another table to list experiences with in months, and finally another table that will basically say “this user has this number of years / months experience for this speciality”
but having a table for experience is months and another table for experience in years kinda sounds redundant, but I can’t think of another way to do it. Is my design fine ?
Here's one idea:
User_ID Skill_ID Experience unit
1. 101 7. Year
1. 102. 4. Month
2. 101. 9. Month
You can simply make a table candidate_experience which has the following columns :
candidate_id which indicates the id of the candidate
specialty indicates the name of the specialty
in_years indicates the number of experience in years
in_months indicates the number of experience in months
You can just make a single table. Without the need to do 4 separate tables.
P.S: You may need to make a composite primary key (candidate_id , specialty) to avoid duplication of same specialty for the same candidate.
^^ This is of course if you are sure that there is no multiple specialties with the same name. Else, you can make a separate specialties table as you did and replace specialty with the specialty_id in the candidate_experience table
Related
A friend who is a recruiter for software engineers wants me to create an app for him.
He wants to be able to search candidates' CVs based on skills.
As you can imagine, there are potentially hundreds, possibly thousands of skills.
What's the best way to represent the candidate in a table? I am thinking skill_1, skill_2, skill_n, etc, but somewhere out there there is a candidate with more than n skills.
Also, it is possible that more skills will be added to the database in future.
So, what's the best way to represent a candidate's skills?
[Update] for #zohar, here's a rough first pass at teh schema. Any comments?
You need three tables (at least):
One table for candidates, that will contain all the details such as name, contact information, the cv (or a link to it) and all other relevant details.
One table for skills - that will contain the skill name, and perhaps a short description (if that's relevant)
and one table to connect candidates to skills - candidatesToSkills - that will have a 1 to many relationship with both tables - and a primary key that is the combination of the candidate id and the skill id.
This is the relational way of creating a many to many relationship.
As a bonus, you can also add a column for skill level - beginner, intermediate, skilled, expert etc'.
You might also want to add a table for job openings and another table to connect that to the skills table, so that you can easily find the most suitable candidate for the job based on the required skills. (but please note that skills is not the only match needed - other points to match are geographic location, salary expectations, etc'.)
The table below is from a tutorial where the tables are in 3rd normal form. But if I insert information into the table PROJECT as follows:
projectCode projectDescr customerNo
1 Apples 21
1 Apples 22
Didn't I lose the 3NF cos the projectcode and projectdescr ends up repeating since 2 customers could possibly have the same project?
So my question is whether the table in the image below is in 3NF. And does the above problem even exists or I am looking at it wrongly? I am setting up my own table but before that I am trying to get the 3NF understanding right. Please help. Thanks.
The table from the tutorial:
The assumption in the example would be that the relationship between PROJECT and CUSTOMER is many to one. A customer may have multiple projects but each project applies to only one customer. If you want a project to apply to multiple customers, then you need to split out another project_customer table that just contains a project and customer key for each row.
I’m new to SQL so please forgive if my terminology is a little out. I’m using phpMyAdmin v3.4 and MySQL (server version) v5.5, I’m building a simple database (only 3 or 4 tables) as a goodwill gesture for my golf club that allows a member to sign-up to play in competitions held on a Saturday or Sunday. The Member may play on both days if they wish (and if they have the energy!) but they may only play once a day. Tables are:
MEMBERS: memberName, memberID
TEE_TIMES: day (choice of Saturday or Sunday), time
BOOKINGS: day_FK, time_FK, memberID_FK, bookingRef
Problem I have with the BOOKINGS table is that I currently have memberID_FK as unique which is fine 95% of the time as most members would play on one day or the other and hence they would only appear in the table once. However, there will be the odd member who will wish to play on “both” days. I could get around this by having 2 BOOKINGS tables (rather than 1), e.g. BOOKINGS_SATURDAY and a separate table for BOOKINGS_SUNDAY, however I believe that would be bad practice and inefficient as I’d have 2 identical table structures (albeit with different names) to manage rather than 1.
I guess what I’m asking is can (memberID_FK) uniqueness be switched on or off depending on another constraint or other variable within a table (in this case the day of choice) - perhaps some kind of clever / dynamic relation between memberID_FK and day_FK? I’d rather implement this as a SQL table structure as I’m not yet familiar with coding although, I’m totally open to a different way of achieving the end goal e.g. splitting the table further (rather than duplicating the structure).
Use a composite unique key:
CREATE TABLE Bookings
...
UNIQUE KEY member_day (memberID_FK, day_FK)
FK are not unique, they usually are on the many side of a one - many relationship.
Make a unique key across member_id and day (maybe even include time ?)
The PK (in your case the memberID from the members table and the day from the tee times table) should be unique, But the FK side is ok not to be unique
So I have this application that I'm drawing up and I start to think about my users. Well, My initial thought was to create a table for each group type. I've been thinking this over though and I'm not sure that this is the best way.
Example:
// Users
Users [id, name, email, age, etc]
// User Groups
Player [id, years playing, etc]
Ref [id, certified, etc]
Manufacturer Rep [id, years employed, etc]
So everyone would be making an account, but each user would have a different group. They can also be in multiple different groups. Each group has it's own list of different columns. So what is the best way to do this? Lets say I have 5 groups. Do I need 8 tables + a relational table connecting each one to the user table?
I just want to be sure that this is the best way to organize it before I build it.
Edit:
A player would have columns regarding the gear that they use to play, the teams they've played with, events they've gone to.
A ref would have info regarding the certifications they have and the events they've reffed.
Manufacturer reps would have info regarding their position within the company they rep.
A parent would have information regarding how long they've been involved with the sport, perhaps relations with the users they are parent of.
Just as an example.
Edit 2:
**Player Table
id
user id
started date
stopped date
rank
**Ref Table
id
user id
started date
stopped date
is certified
certified by
verified
**Photographer / Videographer / News Reporter Table
id
user id
started date
stopped date
worked under name
website / channel link
about
verified
**Tournament / Big Game Rep Table
id
user id
started date
stopped date
position
tourney id
verified
**Store / Field / Manufacturer Rep Table
id
user id
started date
stopped date
position
store / field / man. id
verified
This is what I planned out so far. I'm still new to this so I could be doing it completely wrong. And it's only five groups. It was more until I condensed it some.
Although I find it weird having so many entities which are different from each other, but I will ignore this and get to the question.
It depends on the group criteria you need, in the case you described where each group has its own columns and information I guess your design is a good one, especially if you need the information in a readable form in the database. If you need all groups in a single table you will have to save the group relevant information in a kind of object, either a blob, XML string or any other form, but then you will lose the ability to filter on these criteria using the database.
In a relational Database I would do it using the design you described.
The design of your tables greatly depends on the requirements of your software.
E.g. your description of users led me in a wrong direction, I was at first thinking about a "normal" user of a software. Basically name, login-information and stuff like that. This I would never split over different tables as it really makes tasks like login, session handling, ... really complicated.
Another point which surprised me, was that you want to store the equipment in columns of those user's tables. Usually the relationship between a person and his equipment is not 1 to 1 and in most cases the amount of different equipment varies. Thus you usually have a relationship between users and their equipment (1:n). Thus you would design an equipment table and there refer to the owner's user id.
But after you have an idea of which data you have in your application and which relationships exist between your data, the design of the tables and so on is rather straitforward.
The good news is, that your data model and database design will develop over time. Try to start with a basic model, covering the majority of your use cases. Then slowly add more use cases / aspects.
As long as you are in the stage of planning and early implementation phasis, it is rather easy to change your database design.
My question is more of trying to understand what and how I can get something done. Here's the thing:
I got a job to build this application for a school to manage student bio data, work-out and handle student information and basic finance management.
Based on requirements I got from meets with my client, I have an ERD of a proposed MySQL Database with 23 different tables. The one part I would like to understand quickly is displaying data based on school terms. There are 3 terms in a year, each with its own summaries at the end of each term. At the end of 3 terms, a year has gone by and a student is promoted or demoted.
So my question is, how can I render my data to show 3 different terms and also to create a new year working out how to either promote a student or make the student repeat the class its in?
23 different tables? I'd like to see that model.
I don't think you should have one table per term. You'll have to keep adding tables every term, every year.
Sounds like a transcript table should have term and year columns that are incremented or decremented as a student progresses through. It should also have a foreign key relationship with its student: it's a 1:1 between a student and their transcript.
I would have a separate transcript table because I'd prefer keeping it separate from basic personal information about a student. A transcript would refer to the courses taken each term, the grade received for each, and calculate overall progress. If I queried for the transcript for an individual student, I should be able to see every year, every term, every course, every grade in reverse chronological order.