2

我正在考虑在我工作的一家新公司设计一些核心信息系统（在工作流系统中描述了我的一个想法）

我想得更多，并且正在强烈考虑使用 sharepoint 来完成很多繁重的工作，因为它提供了很多开箱即用的功能。

但是，我不确定它将如何处理我们将向其发送的大量数据。我阅读了 MS 白皮书 ( http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409 )，它说列表中的大约 2000 项是关于使用传统设计方法的限制。

但首先是关于我的计划和数据结构的一些信息：

我们有多个客户。每个客户端都有多个应用程序。每个应用程序将有多个正在进行的作业（或进程运行）。

每个应用程序都将存储重要的通信和文档。每个作业代表单次运行对数据文件的处理，并存储有关作业的信息，例如 postscript 文件、邮政清单等。

工作量约为每天 50 - 100 个。每个作业都有一个由外部程序触发的工作流。然后，例如在“作业调度程序”页面上，生产人员可以安排作业并对作业执行自定义操作（编写为插件）。

我在想这些工作会放在外面并通过 BDC 访问，但我仍然希望它们出现在共享点列表中，以添加共享点功能和报告，并且可以在多个地方访问它们

例如

  • 申请门户 - 查看申请职位
  • 生产调度程序 - 查看即将进行的作业列表、分配给资源、触发其他功能（例如将打印文件复制到打印机、生成邮件机文件）
  • 发票视图 - 查看已完成但未开票的工作，导出到会计包
  • 客户视图 - 客户门户显示工作、发票、库存水平（来自外部仓库系统）、文档、变更登记/帮助台

因此，有关作业的基本信息将位于 BDC 中，但随后 sharepoint 将捕获有关每个作业的附加元数据。此外，我们可能会使用 WF 或 K2 blackpoint / blackpearl 之类的东西加入更高级的工作流程。

这可行吗？您建议阅读任何资源以加快速度吗？

4

4 回答 4

4

要使用 SharePoint，您应该专注于 SharePoint 擅长什么以及它的设计目的。

SharePoint 是一个很棒的协作门户，它不如简单的大容量数据库好。所以...

您可以为每个客户设置一个小站点，并为每个作业设置子站点。“工作站点”的目标是显示（可能使用 Web 部件）相关的即将到来的工作、工作错误/异常列表以及每个工作的相关团队文档。

可以创建单独的站点以给出工作的特定“视图”。例如，可以创建一个“发票”站点以再次从 BDC Webparts 中查看需要发票的内容。

https://iwsolve.partners.extranet.microsoft.com/SDPS/可能会提供一些帮助。

不要试图在 SharePoint 列表中存储大量信息，因为它可能会用元数据“标记”它。如果需要，数据库表完全能够包含提供附加信息的列。

这样想吧。如果您每天创建 50 到 100 个作业，则将这些数据放入列表中的前提是您的站点用户将希望手动输入这些作业的元数据。我认为不是，因此创建您需要的系统，以便在源中正确存储元数据，或在 SharePoint 列表中存储有关作业“类型”的元数据，并允许 SharePoint 将作业类型与 BDC 中的作业相匹配。

SharePoint 将帮助您将所有系统信息集成在一起，但不幸的是，您似乎有很多工作要做，只是计划哪些信息应该去哪里以及每种类型的用户将如何查看它。

于 2009-06-01T22:18:29.320 回答
2

请查看我写的这篇关于管理大型 SharePoint 列表以获得更好性能的博客文章- 它可能会为 2,000 项问题提供一些解释，这实际上并不是对列表中项目数量的硬性限制，因为SharePoint 将支持每个列表最多 500 万个项目。解决此问题的一种方法是创建和维护按索引字段过滤的不同视图，以向您显示不同的项目，一次最多 2,000 个。希望有帮助。

Dina Ayoub 项目经理 Windows SharePoint Services

于 2009-06-02T22:50:25.107 回答
0

棘手的问题 Dane... 在发表意见之前，我想进一步了解您的设计/愿景。

根据我在您的问题中读到的内容，我不会将 SharePoint 2007 用作此应用程序的开发平台。

1) 在 SharePoint 2007 中的开发体验有时会很痛苦，而且效率低下。

  • 难以调试
  • 陡峭的学习曲线

2）容易陷入性能问题

  • 数据层很复杂，可能需要专业的 SQL/SharePoint 管理员技能来扩展平台。
  • 内容数据库不应超过 100 GB。

3) 部署可能非常困难，具体取决于您在做什么。

4) 新版本将在未来 12 个月内发布。

只是我的 .02。

于 2009-06-01T02:26:34.783 回答
0

SharePoint 可能非常适合 UI 方面，但您需要仔细考虑哪些部分存储和修改在 SharePoint 列表中，哪些部分存储在其他位置。这与其说是 SharePoint 问题，不如说是当您拥有多个数据源时您必须始终处理的问题。

我可能会使用 SharePoint 列表作为作业的主要存储，以避免任何同步问题并使编辑更容易。数据量应该不是问题——只要确保你没有尝试一次显示 2000 个项目——在大量项目上遇到性能问题的是视图，而不是列表本身。

于 2009-06-01T05:17:34.713 回答