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