是否有一个根本不使用的主键列的原因？

Question

我有一个例程将创建单个表( Server 2008)，以存储我的应用程序(Asp.net 3.5)生成的报表的结果。每个报表都需要自己的表，因为表的列将根据报表设置而有所不同。一个表将包含10-5,000行，很少超过10,000行.

将适用下列使用规则：

• 一旦存储，数据将永远不会被更新。
• 每当访问表的结果时，将检索所有数据。
• 没有其他表需要对此表执行联接。

知道了这一点，是否有理由在表上创建一个PK索引列？这样做将以任何方式帮助检索数据的性能，如果可以的话，这是否会超过插入数据时更新索引的额外工作量(我知道10K记录相对较少，但是这个解决方案需要能够扩展)。

Update：下面是关于正在处理的数据的更多详细信息，这些信息将进入当前每个报表中的一个表的设计决策：

• 表将记录一组数值(根据报表设置在运行时设置)，这些数值对应于一组不同的引用varchar值(也是根据报表设置在运行时设置的)。
• 无论何时检索数据，都需要在服务器上进行一些后处理，然后才能将输出显示给用户(因此，我将始终检索所有值)。

我也会怀疑有人声称，他们必须为每次运行报告创建一个新的表格。但是，考虑到在每次运行报告时都可能需要不同的列(无论是数量、名称还是数据类型)，我看不出有什么好的选择。

我唯一能想到的另一件事是有一个ID列(标识对应于另一个表的ReportVersionID )、ReferenceValues列(varchar字段，按指定的顺序包含所有引用值，用某种分隔符分隔)和NumericValues列(与ReferenceValues相同，但对于数字)，然后当我检索结果时，将所有内容放入系统中的专用对象中，根据定义的分隔符分隔值)。这看上去更好吗？

Answer 1

主键不是对任何数据表和所有数据表都必须的。的确，它们通常是非常有用的，抛弃它们是不明智的。然而，，，除了一个主要的速度任务(我同意这一点肯定会受到积极的影响)，也是独一无二的。为此目的，并评估您显然已经考虑过的问题，我建议对主键的唯一需要是控制表的预期唯一性。

更新:您在评论中提到的，如果您这样做了，它将包含一个标识列，该列目前不存在，也不需要。在这种情况下，我建议完全反对PK。正如@RedFilter所指出的，代理键从不添加任何值。

Answer 2

我会保持简单，只需将转换为json或xml的报表结果存储在VARCHAR(MAX)列中。

Answer 3

数据完整性(首先是主键和外键引用)最有用、最不被强调的好处之一是，它强制您的数据和应用程序之间进行“契约式的设计”；它阻止了许多类型的bug对数据造成的任何损害()。这是一场巨大的胜利，也是一件默默无闻的事情(保护它的不是‘数据库’，而是您指定的完整性规则；放弃了将数据暴露给不同级别降级的规则)。

这对您来说似乎不重要(因为您甚至没有讨论什么是可能的主键)，而且您的数据似乎与系统的其他部分完全无关(因为您不会连接到任何其他表)；但是--尽管如此--如果所有条件相同，我将正确地对数据建模，然后如果不使用主键(或其他数据完整性规则)，如果追求最后一点性能，我将考虑在生产中放弃它们(并测试任何实际收益)。

至于关于创建表是性能问题的注释--这是真的，但您没有告诉我们这些表是临时的吗？一旦创建，它们会在报废前大量使用吗？或者您是否计划创建仅供十几个读取操作使用的表。

如果大量使用这些表，如果要提供干净的机制来管理这些表(在不使用时删除它们，选择它们，等等)我认为动态创建表是非常好的(您可以更多地分享有关表本身的详细信息；用例会更好)

关于其他解决方案的说明：

EAV模型

是可怕的，除非满足了非常具体的条件(例如:灵活性是至高无上的，自动化DDL太麻烦了)。远离它(或者非常，非常好地预测您需要处理哪些类型的查询，并且在前端验证数据时要非常严格)。

XML/BLOB方法

如果您要在表示层以XML/ be的形式使用数据(始终读取所有行，始终写入整个“对象”，最后，如果表示层喜欢XML/BLOBS)，则可能是正确的选择。

编辑：也是，根据使用模式的不同，主键确实可以提高检索速度，如果我能够读取数据不会被更新的事实，因为‘它将被写入一次并多次读取’，那么它很有可能确实会增加更新插入索引的成本。