关系数据库 - 设计领域的更好选择

在下面列出的两个表“CLASS”和“SECTION”中，对于“CLASS”表中的每个“YEAR-CLIENT_ID-CLS_SEQ”组合，“SECTION”表中将有1个或多个条目。

信息： 两个表CLASS和节主数据，即，建立手工完成，没有计划更新完成。还有其他的使用CLS_SEQ和SEC_SEQ的子事务表;并且所有的事务表也有YEAR和CLENT_ID列。

查询： 就表设计而言，CLS_SEQ和SEC_SEQ哪个选项更好？

由于它们是主数据设置，因此我的选择是选项1，因为它提供了数据的清晰度，并且使得年复一年易于维护。同样在选项1中，还可以通过将YEAR和CLIENT_ID（在应用程序中始终可用）与CLS_SEQ和/或SEC_SEQ一起传递来检索其他事务表中的数据。

我的问题是，如果使用选项1检索连接中的数据&，它是否会对性能产生严重影响？因为无论何时我需要使用来自任何子/事务表的连接从CLASS或SECTION表中提取'一些数据'，我总是需要使用YEAR和CLIENT_ID字段。

另请注意，只有最后4年的记录将保留在所有主表和交易表中，其余的将被存档。

来源

2016-12-16 user5281896

我建议去选择1

看你的数据集（而事实上，你将在4年后清除），它看起来并不像它的将有记录这将数真的会影响性能。此外，如果性能是一个问题，还有其他选项（查询优化，定义索引等）可以在担心如何构造数据之前完成。

从技术上讲，在选项2中，您使用节序列作为唯一的ID。如果你使用它来获取其他表，它肯定会使它成为单一的主键，并因此稍微快一点。

另一方面，您将增加应用程序的复杂性，因为您可能需要在内存中保留一个额外的密钥。

在我看来，它不值得麻烦。数据库的速度足以处理一个连接。它不值得复杂你的代码。

来源

2016-12-16 10:49:43

谢谢你，并感谢你的时间。你能否详细阐述一下“需要在你的记忆中保留一个额外的钥匙”。我实际上已经实施了Option-2，但是对此感到不舒服。在CLASS和SECTION表中，我希望记录的数量以1000s（最大10000s）运行，但其他事务表可能有100万条记录。不过我也认为Option-1是最好的，因为这些表格是手动维护的，它可能是Option-2的噩梦。 – user5281896

我的假设是，在使用其他尚未共享的表格时，您将使用段序列键。由于这是派生键，因此每次需要访问其他表时，都需要将其保存在某个位置，或者从主表中获取该表。如果使用选项1，则可以始终访问其他表（如果有输入）。 –

再次感谢。其他子表与检查，标记等一样，其中CLS_SEQ（OR）SEC_SEQ将是外键。所有必需的输入字段Year，Client_id，Cls_seq/Sec_seq将始终可用作读取/连接表的输入。 – user5281896

关系数据库 - 设计领域的更好选择

回答

相关问题