Schemaless DBs: Indexing dynamically-typed things by their properties?

In a RDBMS you can declare types (tables) and subtypes (subtype tables with supertype FKs). In Rails this would be Class Table Inheritance. For example, you could have Person table and a Friend subtype table with more personal details about the person (e.g. Birthday/Anniversary).

When you leap into the NoSQL world and use a document DB like MongoDB implementing subtypes is much easier since collections are schema-less. This is ideal for creating a CMS. You can now dynamically type anything. In fact, a thing can be multi-typed having the properties of all its types. Not too tricky either.

But here's the tricky part. You want to index your dynamically typed things (e.g. your "things" collection). You want to search for Event things by start_date. You want to search for People things by name. You want to search for Friend things by birthdate. When you're not dynamically typing things each of these types would have its own collection. Indexing Events, People, Friends as dynamically-typed things is tough. Indexing Events, People, Friends as types (tables or collections) is not so tough.

It seems to me MongoDB (and other schema-less databases) were made for dynamic typing. At least, in most respects. But when it comes to indexing dynamically-typed things, it falls short. How have/would you tackle this problem?

I think if MongoDB introduces filtered indexes we'll be there. (Filtered indexes solve the problem in a way that multikeys and sparse indexes cannot.) The only other thing it wou开发者_高级运维ld need is a potentially unlimited number of indexes (since we could have users creating lots of custom types). Without an uncapped number of indexes this would pose a limitation on the number of types such a database could handle.

Please vote in support if you agree that filtered indexes could solve the dynamic-typing issue.

This question simplifies and clarifies a question I asked earlier. It also comes at the problem from a different angle.

---

Speaking from MongoDB POV, there is no reason why you couldn't set up a separate index for each subtype. MongoMapper, specifically (I don't know about Mongoid), will add a _type key to your collection that represents each subtype. You can use this _type key in your index in order to get a filter of sorts.

db.people.ensureIndex({_type:1,birthdate:1})

And so on.