我正在考虑在我正在工作的一家新公司设计一些核心信息系统（在Workflow system描述我的一个想法）
我已经考虑了一些，并且我正在考虑使用sharepoint进行大量的繁重工作，因为它带有如此多的开箱即用。
但是，我不确定它将如何处理我们将要投入的大量数据。我阅读了MS白皮书（http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409），并说明使用传统设计方法，列表中的大约2000项是关于限制的。
但首先是关于我的计划和数据结构的一些信息：
我们有多个客户。每个客户有多个应用程序。每个应用程序都有多个正在进行的作业（或流程运行）。
每个应用程序都会存储重要的信件和文档。每个作业代表一次运行中数据文件的处理，并存储有关作业的信息，如postscript文件，邮政清单等。
每天工作量约为50-100。每个作业都有一个由外部程序触发的工作流程。然后，在“作业调度程序”页面上，生产人员可以安排作业并在作业上执行自定义操作（写为插件）。
我认为这些工作会放在外面并通过BDC访问，但我仍然希望它们在sharepoint列表中表示，添加sharepoint功能和报告，并且可以在多个位置访问
e.g。
因此，有关该作业的基本信息将位于BDC中，但随后sharepoint将捕获有关每个作业的其他元数据。此外，我们可能会使用WF或K2 blackpoint / blackpearl等更高级的工作流程。
这可行吗？您建议阅读的所有资源以加快速度？
答案 0 :(得分：4)
要使用SharePoint，您应该专注于SharePoint擅长的内容及其设计目标。
SharePoint是一个出色的协作门户，它不如简单的高容量数据库好。所以......
您可以为每个客户设置一个小型网站，并为每个工作设置子网站。 “工作现场”的目标是显示（使用webpart）相关的即将到来的工作，工作错误/例外列表以及每项工作的相关团队文档。
可以创建单独的站点以提供作业的特定“视图”。例如，可以创建“开票”网站，以便从BDC网站上再次查看需要开具发票的内容。
https://iwsolve.partners.extranet.microsoft.com/SDPS/可能会提供一些帮助。
不要尝试在SharePoint列表中存储大量信息，只是因为可以使用元数据“标记”它。如果需要，数据库表完全能够包含提供附加信息的列。
以这种方式思考。如果您每天创建50-100个作业，则将该数据放入列表预先假定您的站点用户将要手动输入这些作业的元数据。我没想过，所以创建所需的系统，以便在源代码中正确存储元数据，或者在SharePoint列表中存储有关作业“类型”的元数据，并允许SharePoint将作业类型与BDC中的作业相匹配。
SharePoint将帮助您将所有系统信息集成在一起，但遗憾的是，您需要做很多工作才能规划哪些信息应该放在何处以及每种类型的用户将如何查看它。
答案 1 :(得分：2)
请看一下我在管理大型SharePoint列表时所写的blog post以获得更好的性能 - 它可能会对2,000项问题提供一些解释，这实际上并不是对数量的严格限制。列表中的项目，因为SharePoint将支持每个列表最多500万个项目。解决此问题的一种方法是创建和维护不同的视图，这些视图按索引字段进行过滤，以显示不同的项目，一次最多2,000个。希望有所帮助。
迪娜阿尤布 项目经理 Windows SharePoint Services答案 2 :(得分：0)
严峻的问题丹麦人......在发表意见之前，我想更多地了解一下你的设计/愿景。
根据我在您的问题中阅读的内容，我不会将SharePoint 2007用作此应用程序的开发平台。
1）SharePoint 2007中的开发经验有时会非常痛苦和无效。
2）容易遇到性能问题
3）根据您的工作，部署可能非常困难。
4）新版本将在未来12个月内发布。
只是我的.02。
答案 3 :(得分：0)
SharePoint可能非常适合UI方面，但您需要仔细考虑在SharePoint列表中存储和修改哪些部分以及哪些部分存储在其他位置。这不是一个SharePoint问题，而是当您拥有多个数据源时，您始终需要处理的问题。
我可能会使用SharePoint列表作为作业的主要存储，以避免任何同步问题并使编辑更容易。数据量不应该是一个问题 - 只要确保你不是要同时显示2000个项目 - 这是视图，而不是列表本身会遇到大量项目的性能问题。