爲什麼live projections是索引（TransformResults屬性）的一部分？索引用於文檔查詢，而投影用於文檔轉換。那麼他們爲什麼要合併？RavenDb爲什麼TransformResults放置在索引
如果實時預測不是指數的一部分，那麼可能會對同一指數進行多次實時預測。結果會有更少的索引，我猜RavenDb的性能會好一些。
更新。通過在查詢中放置Select語句（例如Where for filtering），可以進行實時投影。
這實際上是一個公平的問題。我認爲答案是將TransformResults放在索引中是最常見的用例，並且考慮到RavenDB中的現有索引結構，更容易實現。
如果有真實場景，您希望在查詢時以特別方式定義TransformResults，請在郵件列表中發佈功能請求。
不過我敢肯定的答案將是
我會接受一個拉請求
當你是第一人，要求此功能; - ）
到這裏看看：http://ravendb.net/docs/client-api/querying/handling-document-relationships
最重要的部分是這樣的：
在TransformResults聲明的功能上的查詢結果來執行
這意味着，在TransformResults函數將在查詢時執行，而不是索引時間。這顯然是一個根本的區別。
你是對的，他們是不同的。但問題是爲什麼他們如此不同都被置於索引之內。對於我來說，實時投影看起來更像是查詢的一部分（比如Where cluase），而不是索引的一部分。 – SiberianGuy 2012-01-27 07:30:50
因爲我們需要一個地方來放置它們，所以大多數索引只有一個轉換結果函數，所以這是一個很好的選擇。它也減少了你必須知道的關於RavenDB的事情的數量。否則，你將有一個稱爲變形金剛的頂級關注點，因爲這通常只能用於單個索引，因此引發了問題的原因。
把投影放入查詢的Select方法怎麼樣？所以我可以使用Order來排序，在哪裏進行過濾，並且能夠使用Select進行投影會很好。 – SiberianGuy 2012-01-29 17:22:54
您可以在某種程度上做到這一點，請參閱http://stackoverflow.com/a/7836337/4500 – 2012-01-29 17:57:28
這不是我不能沒有的功能。但是我總是認爲預測是通過Select語句來工作的，所以我很驚訝地發現預測工作不是通過Select。 – SiberianGuy 2012-01-27 13:03:04
你有一些選擇，看到這個答案http://stackoverflow.com/a/7836337/4500 – 2012-01-29 17:56:47