我已經完成了一天 2 在陽光明媚的李約瑟快速培訓, 馬, 和我爆破的想法 (對我做的所有良好的培訓類). 一種特定的快將我一直想和我想要把它寫下來，雖然它仍然新鮮和正常的日常"東西" 把它踢我的頭.
我們 SharePoint WSS 3.0 / MOSS 執行者經常面臨的棘手的問題與任何合理規模的 SharePoint 專案: 我們怎麼載入到 SharePoint 等，這一切都符合我們的完美設計的資訊體系結構內的所有未加標籤的資料?
往往不夠, 這不是這種硬的問題，因為我們範圍自己惹上麻煩: "我們不在意什麼都多 3 個月大。" "我們會處理所有的舊東西用關鍵字搜索，會前我們會做到以正確的方式…" 等.
但, 如果我們不能範圍自己走出困境，我們來看看上千 10年或 100 的數千人會發生什麼 (或甚至數以百萬計) 文檔 — 載入 和 加標籤的是我們虔誠的心願?
快速可能是答案.
快速的搜索過程包括大量的移動部件，但這是一個簡化的視圖:
- 編目程式進程查找的內容.
- 它查找內容並將其傳給管理的文檔處理器池的代理進程.
- 代理進程將其傳給一個文檔處理器.
- 文檔處理器分析文檔中並通過管道進程, 分析出文檔 bejeezus 並將其傳給索引產生器類型過程.
關於快速星艦, 我們有大量的文檔處理管道的控制權. 我們可以混合和匹配對 100 管道元件和, 最有趣的是, 我們可以編寫我們自己的元件. 就像我說的, 快速分析文檔各個方向但周日和它在編譯時很多關於這些檔的有用資訊. 那些瘋狂的快速人是瘋狂地癡迷于文檔分析，因為他們有工具和/或戰略，真正對文檔進行分類.
所以 … 快速結合使用和我們自己的自訂管道元件, 我們可以抓住快速從所有這些上下文資訊並回饋到苔蘚. 它可能會變成這樣:
- 從青苔快速送入文檔.
- 正常瘋狂強迫症快速文檔分析和分類發生.
- 我們自己自訂管道元件滴一些上下文資訊關閉到資料庫.
- 我們自己設計的一個進程讀取的上下文資訊, 如何適應內我們 IA 的 MOSS 文檔做出一些決定和標記使用的 web 服務和物件模型.
答案是肯定的, 沒有這種自動化的過程可以是完美的但由於癡迷 (和可能 insane-but-in-a-good-way 快速人), 我們可能有一個真正的戰鬥射擊在一個真正有效的品質負荷的過程，不僅僅是不會填滿一個 SQL 資料庫和一群幾乎沒有可搜索文檔.
</結束>
