如何设计一个主实体表有 25+ 列但单个实体的列平均填充 <20% 的数据库？答案

【问题标题】：How to design a database where the main entity table has 25+ columns but a single entity's columns gets <20% filled on average?如何设计一个主实体表有 25+ 列但单个实体的列平均填充 <20% 的数据库？
【发布时间】：2010-04-17 09:40:17
【问题描述】：

要存储的实体有 25 多个属性（表列）。实体非常多样化，这意味着大多数列都是空的。我想说，平均而言，不到 20% (

在这种情况下，您是否建议将列序列化，或者创建另一个名为“Property”的表，其中包含所有可能的属性，然后创建另一个表“EntityProperty”，它将属性映射到实体使用外键？还是保持原样？

可能发生这种冗余的示例场景如下：

我们有一个虚构的宇宙，里面有很多行星。我们正在创建一个太空采矿游戏，每个星球都有 30 种不同的矿物含量。大多数行星只有 2-3 种矿物质。

最简单的解决方案是创建一个包含 30 列的“Planets”表，每种矿物对应一个列。这里的问题是，“Planets”表中的大多数行都有 25 多列，其中每一列的值为空或零。因此我们有很多冗余数据。比如说，我们将有 500k-1M 条记录。我猜想保存一个空或零十进制值最多需要一个字节。因此，我们浪费了 500,000-1,000,000 字节的空间，即。最多一兆。

另一种解决方案是创建两个额外的表。我们没有将所有矿物质存储在“行星”表中，而是将它们全部取出并创建一个名为“矿物质”的矿物质表。这将仅包含 30 行，每行用于每种不同的矿物类型。然后，我们创建一个名为“PlanetMineral”的表，其中包含对行星行和矿物行的引用，此外，该表将有一列告诉行星所含矿物的数量。显然，在许多数据库系统中，这会使查询复杂化，因为您必须进行可能的多个连接。我正在使用带有 LINQ to SQL 的 SQL 服务器，它将外键约束搭建到类对象属性中，可通过代码访问。（即。我可以简单地使用planet.Minerals 访问行星所拥有的矿物质）因此，从这个角度来看，它不会增加复杂性。冗余是第一个解决方案的一小部分（如 1/15）。仍然存在一些开销的原因是因为我们需要存储外键。

至于数据查询效率，我真的不知道这两种方案的查询成本会如何。

【问题讨论】：

标签： language-agnostic database-design redundancy

【解决方案1】：

这取决于：

您计划拥有多少个实体（行）？
您对该表运行了什么样的查询？
未来会不会有很多新楼盘？
您打算如何使用这些属性？

您似乎担心简单的桌子会浪费空间？尝试计算使用其他方法节省空间是否真的重要且值得。磁盘（通常）很便宜。

如果行数较少，那么单表可能会更好（更容易实现）。

如果您计划针对属性创建复杂的查询（例如 where property1

如果您计划在未来添加大量新属性，那么 Property/EntityProperties 方法可能会很有用。

我会使用简单的单表方法，因为您的行数很少（

【讨论】：

太棒了！ 500k-1M 行。大多数查询处理检索具有所有相关信息的全部或部分行（用于在具有分页的网站上显示实体列表）。未来不应该有很多新属性，因为我们希望已经记录了所需的列。属性本身的数据变化很小，如果有的话，所以大多数（> 99％）查询处理从数据集中检索。似乎单表方法更合适。

【解决方案2】：

对于数字，我个人会将其保留在 1 个表中。数字被压缩成几个字节，而拥有一个 EntityProperty 表的开销将远远超过它。序列化是一种选择，但这意味着您不能使用 SQL 来搜索或计算属性，您必须获取数据、反序列化，然后进行计算。

【讨论】：