This isn't the complete answer, but hopefully, it can get the job rolling in the right direction for you...
Much depends on how you set up your interface for specifying skills. If you have a value list of skills so that an employer can select "forklift driver" and the job seeker must specify exactly the same thing (not "forklift", for example), then you can use relationships to match the list of skills requested against the list of skills needed.
Of special concern will be whether or not you want to match a list of skills inclusively or exclusively. In other words, if an employer specifies a list of three skills, should the query return a list of job seekers with any one of the listed skills or only those that listed all three?
My guess is that you would want to do an inclusive search--find for any one or more of the listed skills, but then sort the results by "relevance" to list the applicants with the most number of skill matches first.
And there are two ways that you can use to collect a list of skills for an employer or a job seeker: 1) use a text field with a checkbox group or 2) use a related table of "skills" records. Of the two, the related table, which can use a portal to list/create/edit a skills list, is more flexible, offering more options for searches, sorts and reports. Oh yes, and a master "skills list table" with a text field to name the skill and an ID number skill to use with value lists and relationships would be a good idea.
Yes I have the job bank administrator working on a standardized list of skills based on the skills requested and skills possesed extracted from past spreadsheet records. So both the Employer Skills and Job Seeker skills will match the standardized table.
My concern is more setting up the form to do the match of skills: kind of hazy about how that gets done.
But does my analysis of how you want the skills of a seeker to match to the skills posted for a job make sense to you?
To list the skills for a given job:
Jobs::__pkJobID = Job_Skills::_fkJobID
Skills::__pkSkillID = Job_Skills::_fkSkillID
To list the skills of a job seeker:
Seeker::__pkSeekerID = Seeker_Skills::_fkSeekerID
Skills::__pkSkillID = Seeker_Skills::_fkSkillID
If this notation is not familiar: Common Forum Relationship and Field Notations Explained
Matching Job skills to seeker skills is where this now gets interesting and before I spend the time on that, I'd like to be sure the type of matching that I have in mind will work for you. Will it?
Yes I am totally onboard with this.
I am a microsoft Access developer, just not used to Filemaker's methods of finding things.
I can use SQL queries in Access.
Sop how to do the find using these groups is the problem: thanks so much for your detail.
With FIleMaker 12, you can use the ExecuteSQL function to pull up a list of ID's and use that list to pull up a list of job seekers for a job or a list of jobs for a seeker. Since you are familiar with SQL, that's an option to consider.
What I have in mind, however, doesn't use SQL. Putting both sets of relationships on one page, you get:
From a Jobs Layout, a portal to Seeker_Skills can be used to list all Seekers with at least one matching skill, and you can use the Go To Related Records script step to pull up a list of Seeker_Skills records. You can then produce a summary report out of these records where you sort by SeekerID to group them and then use a sub summary layout part to list info from each Seekers record. A summary field can count the number of Seeker_Skills records exist for each Seeker and a special sort option in Sort records can reorder these groups of records to list the seekers with the most matches at the top of the list.
I am working on creating this layout.
A problem I have is that I designed a single Contacts file to contain both Employers and job Seekers, since there are cases where a given individual (not always a company) is both. In fcat they may also be donors.
Made sense to me to avoid duplications but now I need this relationship to include only persons who are job seekers.
Not sure how to do that extracty/condition for the above relationship...?
I'd do the same. But when I list something like this:
I am not showing actual tables, but table occurrences. "table1" and "table2" could both refer to the same data source table.
If table occurrences are an unfamiliar concept, this thread may help: Tutorial: What are Table Occurrences?