Design question on disparate but related data -- separate indexes or combined?

[tacman]

I'm indexing a relational database of museum collections. The main entity is an object, but there's also people, storage locations, materials, etc.

Since each entity has its own set of properties, I've been configuring an index for each entity, so I have a object table, a people table, a location table, etc. I define facets on each table, e.g. object: ['length','width','weight','year_made', 'materials','storage_location'] person: ['birth_year','gender','year_of_death','nationality'], All tables have a "status" that I use for workflows.

I used to have everything in one large index, and every row had a "type" field, e.g. person, object. I ran into issues with the facets and searching because of common fields like "label" and "status". I'm wondering if I should go back to that system and preface each facet with a prefix reflecting the type.

It occurred to me that this is not dissimilar to the tenant filtering recently discussed here.

In short, is it possible to get all the same statistics with everything in the same index and filtering by some sort of discriminator property? Any advantage to this, because less indexes to manage? The object database is usually 100x or more larger than all the support tables combined.

Thoughts?

[tacman]

In particular, I find the fieldDistribution data to be very valuable that is returned in $index->stats(); I guess if every field was prefixed with the type, I'd get the distribution, but that's one of the reasons I went to separate indexes.