我有一个包含许多属性的表，可以将这些属性分组为逻辑组，因此将这些属性放在单独的表中的想法似乎很有吸引力。逻辑组并不代表实体本身。设置组中的一个属性后，也必须设置该组中的大多数其余属性（但不是全部）。组的字段类型一般为VARCHAR(15-20). 也没有BLOBorTEXT字段。
逻辑组不代表子类型，因为它们并不相互排斥。
该实体对阅读的要求多于对写作的要求。因此，一张大桌子看起来很合适。此外，这样就可以避免查询中的连接。我不喜欢这种方法的部分是大量可为空的字段。
寻求专家建议。
如果您的数据域需要的话，可空列（即使是很多列）也没有问题。
另一方面，您说这些列可以按逻辑分组这一事实对我来说意味着可能会发生其他事情。
如果因为不同的列集适用于不同的行集而可以对它们进行逻辑分组，那么您可能会遇到实体子类型的情况。
相反，如果由于列在不同时间应用而可以对其进行分组，那么您可能会遇到标准化问题。例如，如果您的列类似于“一月销售额”、“二月销售额”等，那么这些列应该是子表中的行。
虽然可为 null 的列本身没有任何问题，但连接也没有任何问题。这就是 RDBMS 的谋生之道。
更新：
给出有关列的逻辑组的附加信息：
可以使用 1:1 关系在数据库中表示两种子类型。如果逻辑组是互斥的，则父实体可能具有所谓的分区属性，该属性告诉您哪一种子类型适用。然而，如果没有分区属性，则可能有零个、一个甚至多个子类型同时适用。
同样的基本问题也适用于你在这种情况下该怎么做。
解决这个问题的一个好方法是查看列的逻辑组。逻辑组 A 中的列与逻辑组 B 中的列相同还是完全不同？如果它们不同，则最好在具有可为空字段的单个表中对它们进行建模。如果它们相同，那么这可能表明它们应该是多个子行。
另一个需要注意的线索是，逻辑列组可以拥有自己的生命并开始吸引来自其他表的关系是否有意义。如果逻辑组 B 可能很快就会发现自己拥有另一个表中的多个子记录，那么这可能表明将该组提升为其自己的子类型样式表是有意义的。
最后要考虑的一件事是物理实现。如果逻辑子组的填充非常稀疏，您也许可以将这些列分离到另一个表中以优化物理存储。这一步不应该主动完成。当性能测试证明有必要时，应该进行这种优化。
如果这些都不是真的，那么您最好将可空列保留在原始表中。