【发布时间】：2013-05-31 09:37:27
【问题描述】：
为什么live projections 是索引的一部分（TransformResults 属性）？索引用于文档查询，而投影用于文档转换。那么为什么要把它们结合起来呢？
如果实时预测不是索引的一部分，那么同一索引可能会有多个实时预测。结果索引会更少，我猜 RavenDb 的性能会更好一些。
更新。如果将 Select 语句放在查询中（例如过滤的位置）进行实时投影，那就太好了。
【问题讨论】：
【发布时间】：2013-05-31 09:37:27
【问题描述】：
这实际上是一个公平的问题。我认为答案是，将TransformResults 放入索引是最常见的用例，并且考虑到 RavenDB 中现有的索引结构，更容易实现。
如果确实存在您希望在查询时定义 TransformResults 的真实场景，请以特别的方式在邮件列表上发布功能请求。
但是我很确定答案会是
我会接受一个拉取请求
因为您是第一个要求此功能的人 ;-)
【讨论】：
-
这不是我不能没有的功能。但我一直认为投影是通过 Select 语句起作用的，所以我很惊讶地发现投影不是通过 Select 起作用的。
-
你有一些选择，看到这个答案stackoverflow.com/a/7836337/4500
因为我们需要一个地方来放置它们，大多数索引只有一个转换结果函数，所以这是一个很好的地方。它还减少了您必须了解的有关 RavenDB 的事情的数量。否则，您将有一个称为 Transformers 的顶级关注点，它通常仅与单个索引一起使用，因此提出了为什么它们被分开的问题。
【讨论】：
-
如何将投影放入查询的 Select 方法中？所以我可以使用 Order 进行排序，使用 Where 进行过滤，如果能够使用 Select 进行投影就好了。
-
你可以在某种程度上做到这一点，见stackoverflow.com/a/7836337/4500
看这里：http://ravendb.net/docs/client-api/querying/handling-document-relationships
重要的是：
TransformResults 中声明的函数将在查询结果上执行
这意味着，TransformResults 函数将在查询时执行，而不是在索引时执行。这显然是一个根本的区别。
【讨论】：
-
你是对的，它们是不同的。但问题是为什么它们如此不同都放在索引中。对我来说，实时预测更像是查询的一部分（例如 Where cluase），而不是索引的一部分。