Study multi-criteria indexing

[lecoqlibre]

We demonstrated that it is very easy and efficient to use indexes for searching data with one criteria (ex: skill).

How can we handle multiple criteria?

Ideas:

• Create multi-criteria indexes (ex: skill + city)
• Parse several indexes on the fly
• Save previous results in cache (client and/or server)

Use case examples:

1. we are searching a user given its skills and city.
2. we are searching a user given its skills, city and name.

Parse several indexes on the fly

We are going to chain the indexes: filter the next index with the results of the previous one.

[FabienGandon]

Here we touch the topic of "query solving planning" and the Rubens have this in their future work i.e. to design dedicated query solving planning for traversal query solving on top of SOLID. There is a huge literature on the subject with its roots in distributed databases.

[pchampin]

I agree with @FabienGandon , this is a huge topic. It could quickly become a rabbit hole. There are already a number of questions you need to answer about mono-criterion indexing:

• which properties should I have an index for? (i.e. which properties are likely to be used as search criteria)
• what kind(s) of index should I have for each property? (i.e. how will properties be searched: find a specific value? a range? full-text? for dates: chronological? month-of-year?)

The combinatorics is, IMO, large enough that we don't make multi-criteria indexes a priority. My 2¢ anyway.