在SharePoint表上创建视图的样式是否错误？

我只使用sharepoint三个月，但从一开始我就被告知sharepoint内容数据库是禁止使用的，因为MS可以随时更改模式。推荐的方法是使用对象模型，在大多数情况下，我有点理解这一点

现在我需要加入一些列表，以便显示按某些特定字段分组的内容。与其遍历每个列表，我更愿意将驻留在同一个db服务器上的我们自己的db链接到WSS content db，并在表上创建一个视图。这个视图应该在我们的数据库中，这样我们就不会更改WSS内容数据库中的任何内容

---

我是否在通往永恒诅咒的道路上？

是的，你是。Microsoft非常清楚，对SharePoint表的任何修改都会使您无法支持

现在，在您自己的数据库上创建查询SharePoint数据库的链接是不可靠的。就我个人而言，我会做两件事中的一件：

• 如果这是一个任务关键型应用程序，请通过MSFT支持运行它
• 如果是其他情况，请确保您的视图在查询期间没有锁定数据库

---

更好的策略可能是迭代列表并将其同步到您自己的表中，这样您就可以进行任何类型的数据挖掘—如果您不介意同步例程需要的延迟时间的话。

SharePoint几乎依赖于基础数据库的总体“所有权”。 从SharePoint数据库读取另一个进程之类的小事可能会以意想不到的方式降低SharePoint的运行速度

由于SharePoint通常不会以“实时”方式进行更新，因此它应该足以创建一个查询SharePoint列表并将数据添加到您自己的应用程序中的表中的流程

将爬网安排在一个低活动期，瞧，这是一个解决方案，它不会给SharePoint带来意外减速的风险

---

在以下位置开始查询SharePoint的搜索。

查看SLAM，SharePoint列表关联管理器。它允许您轻松地将SharePoint数据推送到SQL，包括复杂的联接（一对一、一对多、多对多）。它可以实时同步数据

---

好吧，如果您需要执行的连接非常简单，那么在SharePoint Designer中定义一个连接可能对您有用

好吧，但这难道不会带来新的类似蠕虫的并发问题吗？如果更新过程在用户更新其中一个列表的同时运行？请不要认为这将是一个问题，因为将内容放入自己表中的数据爬网将从数据库获取并插入数据库。数据库的设计很好地处理了这个问题。当然，但是在爬虫程序再次运行之前，数据是不同步的。我想我应该把问题清单上的事件联系起来，以尽量减少这个问题。这就是为什么我要说，如果你不介意滞后的话。如果这是超级关键任务（我的意思是，你们都有卓越支持合同，非常重要，yada yada），那么我可以告诉你们资源，如果你们联系我在cornet design.com的foyc。否则，OM和eventing是您的最佳选择