有没有理由让主键列永远不会被使用?

主键不是必须的 对于任何和所有数据表。的确,它们通常很有用,抛弃它们是不明智的。 然而 除了主要的速度任务(我同意这无疑会受到积极影响)之外,还有独特性的任务。为此目的,并重视您显然已经考虑过的因素,我建议只需要一个主键来控制表的预期唯一性。

更新: 您在一条评论中提到,如果您执行了一个PK,它将包含一个标识列,该列目前不存在,也不需要。在这种情况下,我建议完全不要PK。正如@RedFilter所指出的,代理项键永远不会增加任何值。

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

任何损坏 你的数据。这是一个巨大的胜利,而且是一件理所当然的事情(保护它的不是‘数据库’,而是您指定的完整性规则;放弃将您的数据暴露于不同级别降级的规则)。

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

至于创建表是一个性能问题的评论-这是真的,但是您没有告诉我们这些表有多临时?一旦创建,它们会在报废前大量使用吗?或者,您计划只为十几个读取操作创建表。

以防你大量使用这些桌子 如果您能提供干净的机制来管理它们(不使用时删除它们,选择它们等等),我认为动态创建表是非常好的(您可以共享更多关于表本身的细节;用例也很好)

其他解决方案说明:

EAV model

和 严格验证前端数据)。

XML/BLOB方法

如果您在表示层将数据作为XML/blob使用(始终读取所有行,始终写入整个“对象”,最后,如果您的表示层喜欢XML/blob),那么这可能是对的

编辑: 另外,根据使用模式,具有主键 确实提高了检索的速度,如果我能读到这样一个事实,即数据不会更新为“一次写入,多次读取”,那么很有可能确实会增加在插入时更新索引的成本。

它是为给定报表的每次运行提供一个表,还是为给定报表的所有运行提供一个表?换言之,如果您有Report#1,并且在不同的数据范围内运行了5次,那么您将生成5个表,还是将所有5次运行的报表都存储在同一个表中?

如果要将所有5次运行的报表存储在同一个表中,则需要筛选数据,使其适合所讨论的运行。在这种情况下,使用主键可以更快地为过滤器执行where语句。

如果要为报表的每次运行创建新表,则不需要主键。但是,随着系统中表的数量增加,您将遇到其他性能问题。。。假设您没有合适的东西来删除旧数据/表。

如果您真的没有将这些表用作只读数据块以外的任何其他用途,那么您也可以将所有报表作为XML值存储在一个表中。

PK索引将建立在哪些列上?如果只是一个代理项标识列,则在插入行时不会影响性能,因为它们将按“顺序”插入。如果它不是代理项密钥,那么您就有了公认的次要但仍然有用的保证,即您没有重复的条目。

主键是否用于控制报表行的打印顺序?如果没有,那么如何确保信息的正确排序?(或者这仅仅是一个数据表,在生成报表时会以一种方式和另一种方式求和?)

总的来说,我发现虽然不是每个表都需要主键,但是有一个主键存在并没有坏处,而且由于正确的关系数据库设计要求所有表都有主键,所以总是包含它们是一个好的实践。