database-design - 最好有数百列或拆分成多个表？

Question

我正在设计一个关于机械设备运行的统计数据库。每批数据将包含数百个统计信息，因此我试图决定是创建具有数百列的单个表还是将其拆分为多个表，每个表都包含相关的统计信息。例如，我可以有一个包含与故障相关的统计数据的表，另一个包含与卡纸相关的统计数据的表，等等。

使用多个表会使整个系统变得更加复杂，但从概念上讲，处理几个小表可能比处理一个大表更容易。

拆分事物是否有任何性能优势？看起来查询一个有几十列的表可能比查询一个有数百列的表快。

有没有人有这种事情的经验？我在这个项目中使用 Oracle，尽管我将来可能会在没有数据库的情况下遇到这种情况，因此对于任何数据库的答案都将不胜感激。

Answer 1

我认为我们需要更多地了解您的设计才能正确回答。例如，我很好奇可能有很多与故障相关的列，很多(不同的)与堵塞相关的列等等。(无论如何，堵塞不就是一种故障吗？)

你的设计标准化了吗？大概你没有像“jam1”、“jam2”等这样的列？!

假设设计良好且标准化，决定是使用一张宽 table 还是许多窄 table 是各种因素之间的权衡:

是否所有/大多数记录都有所有类型的统计信息？是 => 一张 table ，没有 => 很多

您是否经常需要一起查询所有类型的统计信息？是 => 一张 table ，没有 => 很多

您是否在同一个屏幕上同时维护所有不同的统计数据？是 => 一张 table ，没有 => 很多

您是否可能达到任何数据库限制，例如每个表最多 1000 列？

无论采用哪种方式，您都可以使用 View 来呈现替代结构，以方便开发人员:

一张表:许多 View 选择特定类型的统计信息

许多表:将所有表连接在一起的 View

更新

从您的评论中，我现在知道您在机器上的 40 个不同位置进行了卡纸计数，其他类型的统计数据具有类似的性质。这建议采用以下表格设计:

create table machines (machine_id ... primary key, ...);
create table machine_stats 
   ( machine_id references machines
   , stat_group -- 'jams', 'malfunctions' etc.
   , stat_name  -- 'under the hood', 'behind the door' etc.
   , stat_count 
   );

正如下面有人评论的那样，这些使您可以更轻松地汇总统计数据 - 在统计类型内或跨统计类型。如果需要将新统计数据添加到统计数据类型，它也很容易扩展。