: the search results. In particular, I hypothesize that, for a somewhat : heterogeneous index (heterogeneous in terms of which fields a given : record might contain), that the following rule might be helpful: Facet : on a given field to the extent that it is frequently set in the : documents matching the user's search.
if you go down this route, i suspect you'll find it more interesting to sort the fields based on which facets have the highest average facet count ... consider the (frequently typical) case of fieldX which is the sme for every doc in the result set, or fieldY which is unique for every doc in the result set -- neither of those will make very useful facets for your user (fieldY might, but only if you have some external info about how to sort the field constraints so the "best" values are shown to the the user to help them drill down to the one doc they'd be most interested in) my hunch: even if you implemented a syustem like this, it would probbly only be useful in extremely generic usecases where you have absolutely no idea what data is in your index and you want a useful "exploration" UI. if you have even a little bit of information about your schema and your users, you can probably do a much better job at guessing which fields to facet on first -- and if those fields have very few non-zero constraints for a given query, it's easy to skip them and show the next one in your list. the utility of a facet option in your UI tends to depend a lot more on who your users are then it does on what your index is. -Hoss
