Re: Does a normalized design lead to complex queries?

The complexity you describe is solved by using the IN operator and a
SUBQUERY. Something like the following pseudo-code:

SELECT c.name
FROM candidates c
WHERE c.candidateid IN
(SELECT x.candidateid FROM x WHERE blah AND blah OR complexity...)

The nested SELECT after IN is a subquery that first qualifies a big
list of all things that you are looking for with some multiples in the
candidateid's. The main query then just displays the candidate
information for those that fulfill the conditions. It's basically a
2-step technique. Notice that DISTINCT doesn't need to be used to
suppress the subquery candidateid repeats.

However, if you want to display the competencies of each candidate,
then you do have another problem to solve. But, even with a
denormalized design, you would still have a problem displaying such
disparate info in an easy, friendly way.

Even if you did kludge a denormalized table to do the job, it would be
difficult to maintain over time. Whereas the normalized approach and
leveraging SQL logic can be considered more elegant for taming the data.