Is your feature request related to a problem? Please describe.

The finder's functionality is quite flexible. Though it misses a way to further filter the returned results (links). The reason for the above constraint, is that all the meta-data of the links are stored in a BLOB object in the table #__finder_links, from which the search results come.
Obviously, the contents of the BLOB object cannot be used in sql queries and conditions.

For example what if we want to further filter the results (e.g. show only articles that have the "red" value of the custom field "colour")?
In that case we need to join the links with other tables and to do that we need foreign keys, which now do not exist (only within the BLOB object).

One solution could be to store those foreign keys (id, context), relative to the links, in the tables #__finder_taxonomy and #__finder_taxonomy_map and then join them with other tables.
Though if this is done, the table #__finder_taxonomy_map will become unnecessarily big by storing all the ids of the indexed items. While those properties are unique and strictly related with each link.

Describe the solution you'd like

The addition of 2 columns to the table #__finder_links.
1 will indicate the context and 1 the primary key/parent id of the link's element.
The later has the disadvantage that misses a reference to the table but it is quite easy to find the table by the context. By doing that, new possibilities emerge as the result items can be filtered further with properties from other tables.

Additional context

With the increased use of the com_finder as the default search solution, additional flexibility will be required.

Assignment

I can prepare a PR for the schema and the code changes to generate those db records