数据库性能:使用一个具有最大值的实体/表.可能的属性或拆分到不同的实体/表？

Question

我需要设计一些数据库表,但我不确定性能影响.在我的情况下,它更多地关于读取性能而不是保存数据.

情况

借助模式识别,我可以找到需要在postgresql数据库中保存多少某个对象的值.其他数量让我们说固定属性唯一的区别是需要保存相同类型的1,2或3个值.

目前,我有3个实体/表,它们的区别仅在于具有相同类型的1,2或3个不可空的属性.

例如:

EntityTestOne/TableOne {
    ... other (same) properties
    String optionOne;
}

EntityTestTwo/TableTwo {
    ... other (same) properties
    String optionOne;
    String optionTwo;

}

EntityTestThree/TableThree {
    ... other (same) properties
    String optionOne;
    String optionTwo;
    String optionThree;
}

我希望生产中有数百万条记录,并且我正在考虑这种变体的性能影响以及可能的替代方案.

备择方案

我想到的其他选择:

• 仅使用一个具有3个选项的实体类或表(optionTwo和optionThree将可为空).如果谈论数以百万计的预期记录加上缓存,我问自己,在至少两个(缓存)层(数据库本身和休眠)中保存数百万个空值并不是一种"浪费".在另一个答案中,我昨天读到在postgresql中保存一个空值只需要1比特我认为如果我们谈论数百万条记录可以包含一些可以为空的属性(链接)那么多.
• 创建另一个实体/表并使用集合(列表或集)关系

例如:

EntityOption {
    String value;
}

EntityTest {
    ... other (same) properties
    List<EntityOption> options;
}

• 如果要使用此关系:在创建新记录的情况下,什么会提供更好的性能:为每个新的EntityTest创建新的EntityOption或在之前进行查找并引用现有的EntityOption(如果存在)？稍后获取它们时的读取性能以及当时需要的连接怎么样？与具有三个选项的一个普通实体的变体相比,我可以想象它可能会稍慢......

由于我不是那么强大的数据库设计和使用hibernate我对这些方法的优缺点感兴趣,如果有更多的选择.我甚至想问一个问题,如果postgresql是正确的选择,或者是否应该考虑使用另一个(免费)数据库.

谢谢!

Answer 1

我认为这个案例很清楚:如果每个对象有三个属性的上限,请使用一个具有可空属性的表.

NULL值不占用数据库中的任何空间.对于每一行,PostgreSQL都存储一个包含哪些属性为NULL的位图.始终存储此位图,除非所有属性都不可为空.有关详细信息,请参阅文档
所以在这种情况下不要担心存储空间.

使用三个不同的表或将属性存储在单独的表中可能会导致查询中的UNIONs或JOINs,这将使查询更复杂和缓慢.