: So i'm basically looking for design pattern/best practice for that scenario : based on people's experience.
I've taken two approaches in the past... 1) encode the "id" and the "label" in the field value; facet on it; require clients to know how to decode. This works really well for simple things where the the id=>label mappings don't ever change, and are easy to encode (ie "01234:Chris Hostetter"). This is a horrible approach when id=>label mappings do change with any frequency. 2) have a seperate type of "metadata" document, one per "thing" that you are faceting on containing fields for id and the label (and probably a doc_type field so you can tell it apart from your main docs) then once you've done your main query and gotten the results back facetied on id, you can query for those ids to get the corrisponding labels. this works realy well if the labels ever change (just reindex the corrisponding metadata document) and has the added bonus that you can store additional metadata in each of those docs, and in many use cases for presenting an initial "browse" interface, you can sometimes get away with a cheap search for all metadata docs (or all metadata docs meeting a certain criteria) instead of an expensive facet query across all of your main documents. -Hoss
