SQL - 1 个包含许多 NULL 值或许多小表的大表

Question

我试图了解使用 1 张大 table 还是许多小 table 更好。
我已经通过网络准备好了这取决于每种情况，所以我想根据下面的示例提出任何建议:

假设我想创建一个包含 Assets 所有特征的数据库。 Assets 可以分为不同的 Assets 类别(即股票、债券、现金等)。所有 Assets 类别都具有相似的特征(即 ID 代码、发行人名称)并且一些 Assets 具有特定特征(债券具有到期日而股票没有)。所以我的问题是我是否应该使用一个大表，当 Assets 不适用时，该表将保留为 NULL(如下所示)



还是每次我需要生成报告时，我应该使用几个表作为并加入它们？ (如下所示)



每种情况的利弊是什么？例如，如果我有 1m 个不同的 ID 代码，它是否需要为 1 个表选项增加空间，而使用多表选项查询性能会显着下降？

如果每种类型的独特特征是 50 种，并且有 10 种不同的 Assets 类别，该怎么办？我应该创建一个 50 x 10 = 500 列的表(每行的大部分列都为 NULL)还是应该有 10 个不同的表并在我想创建报告时使用 LEFT JOIN？

Answer 1

您有一个真正的问题，其中包含有关特定应用程序的详细信息。我不确定它是否太宽泛或寻求意见。问题本身很难回答，但让我尝试为您提供回答的指导方针。

你所拥有的是(可能)一种关系。第一个问题:外键关系会在哪个级别？如果一般关系是“ Assets ”，那么就需要一个主键，倾向于单个表。如果每个 Assets 类别都有自己的关系，那么每个 Assets 类别都需要一个主键，倾向于多个表。

当然，您可能希望两者都具有外键关系。有办法解决这个问题。

第二个问题是性能。通常，即使列是空的，更宽的表(尤其是固定长度的列)也会占用空间。所以，如果你有很多很多列，所有的空白空间都会消耗性能。

第三个问题是数据库的特定功能。例如，Postgres 支持表中的继承。这非常准确地适合您的数据模型。 “ Assets ”表可以具有一般属性。然后每个“子”表都可以有自己的属性。

或者，SQL Server 支持稀疏表，这可以减轻在非常宽的表上浪费空间的影响。

第四个问题是安全和访问权限。不同的 Assets 类别对访问有不同的要求吗？在表级别提供访问通常比在行级别提供访问更简单。

第五个问题涉及数据修改。是否所有数据同时插入？不同的 Assets 有不同的更新时间表吗？这如何提供给最终用户查询？这可以建议将数据存储在单独的表中，以隔离更新。或者甚至有一个信息表来跟踪每个 Assets 类别的最新更新。

因此，与您的问题一样详细，还有其他考虑因素会影响决定。