Skip to content

Instantly share code, notes, and snippets.

@felclef
Created August 15, 2011 13:53
Show Gist options
  • Save felclef/1146802 to your computer and use it in GitHub Desktop.
Save felclef/1146802 to your computer and use it in GitHub Desktop.
A script for Elland's sake. I hope it helps :D
/**
* 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