我已经完成了一天 2 在阳光明媚的李约瑟快速培训, MA, 和我我的想法破灭 (对我做的所有良好的培训类). 一种特定的快将我一直想和我想要把它写下来，虽然它仍然新鲜和正常的日常"东西" 把它踢我的头.
我们 SharePoint WSS 3.0 / MOSS 执行者经常面临的棘手的问题与任何合理规模的 SharePoint 项目: 我们怎么加载到 SharePoint 等，这一切都符合我们的完美设计的信息体系结构内的所有未加标签的数据?
往往不够, 这不是这种硬的问题，因为我们范围自己惹上麻烦: "我们不在意什么都多 3 个月大。" "我们会处理所有的旧东西用关键字搜索，会前我们会做到以正确的方式…" 等.
但, 如果我们不能范围自己走出困境，我们来看看上千 10年或 100 的数千人会发生什么 (或甚至数以百万计) 文档 — 加载 和 加标签的是我们虔诚的心愿?
快速可能是答案.
快速的搜索过程包括大量的移动部件，但这是一个简化的视图:
- 爬网程序进程查找的内容.
- 它查找内容并将其传给管理的文档处理器池的代理进程.
- 代理进程将其传给一个文档处理器.
- 文档处理器分析文档中并通过管道进程, 分析出文档 bejeezus 并将其传给索引生成器类型过程.
关于快速星舰, 我们有大量的文档处理管道的控制权. 我们可以混合和匹配对 100 管道组件和, 最有趣的是, 我们可以编写我们自己的组件. 就像我说的, 快速分析文档各个方向但周日和它在编译时很多关于这些文件的有用信息. 那些疯狂的快速人是疯狂地痴迷于文档分析，因为他们有工具和/或战略，真正对文档进行分类.
所以 … 快速结合使用和我们自己的自定义管道组件, 我们可以抓住快速从所有这些上下文信息并反馈到苔藓. 它可能会变成这样:
- 从青苔快速送入文档.
- 正常疯狂强迫症快速文档分析和分类发生.
- 我们自己自定义管道组件滴一些上下文信息关闭到数据库.
- 我们自己设计的一个进程读取的上下文信息, 如何适应内我们 IA 的 MOSS 文档做出一些决定和标记使用的 web 服务和对象模型.
答案是肯定的, 没有这种自动化的过程可以是完美的但由于痴迷 (和可能 insane-but-in-a-good-way 快速人), 我们可能有一个真正的战斗射击在一个真正有效的质量负荷的过程，不仅仅是不会填满一个 SQL 数据库和一群几乎没有可搜索文档.
</结束>
