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

Question

要存储的实体具有25+属性(表列)。实体相当多样，这意味着，大多数列都是空的。平均来说，我会说，在任何特定的项目中，只有不到20% (<5)的属性具有值。因此，对于大多数表行，我有许多多余的空列。几乎所有的列都是十进制数。

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

可能出现这种冗余的示例场景可能如下：

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

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

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

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

Answer 1

这取决于：

• 您计划拥有多少个实体(行)？
• 您对该表运行哪种查询？
• 将来是否会有许多新属性？
• 您计划如何使用这些属性？

你似乎担心简单的表格浪费空间？尝试计算使用其他方法节省空间是否真的重要和值得。这个磁盘(通常)很便宜。

如果您的行数很少，那么单表可能更好(它更容易实现)。

如果您计划针对属性创建复杂查询(例如，其中property1 < 123)，那么简单的表可能更容易。

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

我使用简单的单表方法，因为您的行数非常少(<1M)，您可能是在服务器机器上运行数据库，而不是使用手持/移动设备(SQLServer)，而且您的数据库模式相当严格。

Answer 2

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