无模式数据库：通过属性对动态类型的事物进行索引？
在 RDBMS 中，您可以声明类型（表）和子类型（具有超类型 FK 的子类型表）。在 Rails 中，这就是类表继承。例如，您可以拥有“人员”表和“朋友”子类型表，其中包含有关人员的更多个人详细信息（例如生日/周年纪念日）。
当您跳入 NoSQL 世界并使用像 MongoDB 这样的文档数据库时，实现子类型会容易得多，因为集合是无模式的。这是创建 CMS 的理想选择。您现在可以动态输入任何内容。事实上，一个事物可以是多类型的，具有其所有类型的属性。也不太棘手。
但这是棘手的部分。您想要索引动态类型的事物（例如您的“事物”集合）。您想要按 start_date 搜索事件事物。您想要按名称搜索人物事物。您想按生日搜索朋友的事物。当您不动态输入内容时，每种类型都会有自己的集合。将事件、人物、朋友索引为动态类型的事物是很困难的。将事件、人物、朋友作为类型（表或集合）建立索引并不那么困难。
在我看来，MongoDB（和其他无模式数据库）是为动态类型而设计的。至少，在大多数方面。但当涉及到动态类型的索引时，它就显得不足了。您已经/将如何解决这个问题？
我认为如果 MongoDB 引入过滤索引，我们就会实现这一点。 （过滤索引以多键和稀疏索引无法解决的方式解决了这个问题。）它唯一需要的另一件事是可能无限数量的索引（因为我们可以让用户创建大量自定义类型）。如果没有无限数量的索引，这将对数据库可以处理的类型数量造成限制。
如果您同意过滤索引可以解决动态类型问题，请投票支持。
这个问题简化并澄清了我之前提出的一个问题。它还从不同的角度来看待问题。
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 would 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从 MongoDB POV 来看，没有理由不能为每个子类型设置单独的索引。 MongoMapper，特别是（我不知道 Mongoid），将向您的集合添加一个 _type 键来表示每个子类型。您可以在索引中使用此 _type 键来获取某种过滤器。
等等。
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.
And so on.