Created
August 15, 2011 13:53
-
-
Save felclef/1146802 to your computer and use it in GitHub Desktop.
A script for Elland's sake. I hope it helps :D
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/** | |
* This sh*t is a dummy query to help a jenius fréndo | |
* | |
* The problem: get a dataset with the Job vs Candidate - Skill analysis, and answer: which candidate better fits the given job skills? | |
* | |
* Consider: | |
* - A Job is composed by many Skills | |
* - And so is the Candidate... | |
* | |
* Use your imagination, cuz this is just a dummy script, I wont create any schema... >:D | |
*/ | |
select | |
-- you'd better see the "from clause" before you read the "select clause"... | |
jb.job_id, -- id, description, whatever! | |
cn.candidate_id, -- id, name, whatever! | |
-- after you have defined your dataset (that's why I asked you to read "from" before), we will "count as many matches the condidate has"... | |
-- | |
sum( | |
case | |
-- the trick is simple: when it matches, it isnt null... so we count up once | |
when skc.skill_id is not null then 1 | |
-- ... because of the left join, you have this effect, ta-da! | |
else 0 | |
end | |
) / -- ... and divede it by the number of "matches it could have", that is drive by the "Logical Job dataset". We are done! | |
count(*) as percent_of_aproval | |
from | |
-- assuming that your candidate has many skills and so the skills cloud be used by many candidates. The skill is the "strong entity", because you "always have a job" but the same isn't true for the candidate, isn't it right? (otherwise, we wouldnt have to do the SQL...) | |
Job jb | |
inner join JobSkill jbs | |
on jbs.job_id = jb.job_id | |
inner join Skill skj -- those are trully the job skills | |
on skj.skill_id = jbs.skill_id | |
-- ok, so far, we have a "Logical job with its skills" | |
-- now, to let's assemble the "Logical candidate blablablah" | |
-- I'm using the parenthesis for a better readability and acurrate definition of our dataset | |
left join ( | |
Candidate cn | |
inner join CandidateSkill cns -- see? using parenthesis, I have full controll of join precedences! | |
on cns.candidate_id = cn.candidate_id | |
inner join Skill skc -- weird? np, we indeed need the "twice-joined" table... dont worry, it is fine =D (and still, it's very fast) | |
on skc.skill_id = cns.skill_id | |
) -- note: this isn't a "sub query", thus, CAN'T have any aliases | |
-- now, the trick: | |
-- we need to match "both logical entities". And ye know what ye need, dontchya? | |
on skj.skill_id = skc.skill_id | |
where | |
jb.job_id = {your_filter} | |
group by | |
jb.job_id, -- id, description, whatever! | |
cn.candidate_id; -- id, name, whatever! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment