我正在设计自定义SharePoint应用程序。在以前的项目中，所有数据都保存在SharePoint列表中，这就是我现在一直在尝试的方式。但是，我已经到了数据模型增长的程度，我觉得需要将其标准化并将一个逻辑实体分成几个物理列表。我想知道是否应该从SP列表切换到经典数据库。一方面，我对SharePoint开箱即用的新项目，编辑项目，所有项目表单感到满意;另一方面，我担心一旦我必须查询连接数据（如果它保持在SPList s），性能将受到影响。
如果您对此问题有任何见解或经验，请分享。感谢。
答案 0 :(得分：8)
这取决于您的要求，但根据我的经验，您应该使用数据库而不是列表：
1）当您的数据库模型中存在多对多关系时
2）当您有两个或更多实体链接在一起时（例如，客户＆gt;发票＆gt;发票产品）。
SharePoint非常棒，但在上述方案中，您将遇到SharePoint UI限制问题。
3）如果您计划拥有任何自定义报告或图表，则应该坚持使用自己的数据库。
当您使用数据库实体时，最好的方法是开发自己的Web部件，因为BDC价格昂贵且在大多数情况下非常有限。您还可以检查第三方Web部件（例如Bamboo Web部件）
以下是在数据库上使用SharePoint列表的原因：
答案 1 :(得分：3)
如果您有复杂的查询，我建议您将它们放入单独的数据库中。当数据模型不经常增长时，列表很好。
扩展列表列中的字段数量包括使用您必须编码的STSADM直接更新ContentTypes。但是，直接从数据库查询数据（当然有一些缓存）将导致更快的开发，而无需更新链接到与其关联的每个列表的所有ContentType。
当然，如果激活缓存，则从数据库查询的数据将在页面输出级别缓存。
答案 2 :(得分：1)
除了Maxim的回答，我还建议你考虑一下。如果这些数据是您需要深入研究的话，那么OTB搜索真的很棒。
答案 3 :(得分：1)
我不会太担心去数据的自定义数据库。
这确实意味着使用自定义控件对其进行外观处理，并将这些控件引入布局页面和/或列表为您执行的自定义Web部件。
如果您有可用的BDC，那将是可行的方式，否则自定义。
因此，最终它是在与sharepoint集成的简易性和可用的数据输入表格与编码所有这些项目之间的权衡，但完全控制数据完整性。