Thank you for the explanation and illustrations, @tcoopman !
Indeed, why can’t I query the projections of resumes and vacancies and have matching as a part of a query.
Why would you have to rebuild the whole table on every change?
I somehow had it in my mind that the final projection (or a query to a projection) would be rows of vacancies with matching candidates and the other way around, so for example I was thinking of a projection table sort 'of vacancy having rows like with columns like:
vacancy_id, description, skills_needed, matched_resume_ids_or_even_full_content_as_json_array. With this projection in mind whenever a new resume is posted or removed I guess a system would need not to add a row to a table, but to change/replace the already existing one.
I suppose I would also need to learn how to handle removed/deactivated aggregated. Your image for “resume submitted” events will work perfectly when resumes are only submitted, but now I realize that I will probably need to do something when resume is deactivated for whichever reason (expired, manually unpublished) and I’d want final projections be somehow easily queryable to active resumes only.
