我正在设计一个有关机械设备运行的统计数据库。每批数据将包含数百个统计信息，因此我试图决定是创建一个包含数百列的表还是将其拆分为多个表，每个表都包含相关的统计信息。例如，我可以有一个包含与故障相关的统计信息的表，另一个包含与堵塞相关的统计信息的表，等等。
使用多个表会使系统总体上更加复杂，尽管从概念上讲，处理几个较小的表比处理一个大的表可能更容易。
拆分是否有任何性能优势？似乎查询具有几十列的表可能比查询具有数百列的表要快。
有没有人有这方面的经验？我在这个项目中使用 Oracle，虽然这可能是我将来在没有数据库的情况下会遇到的问题，所以任何数据库的答案都将不胜感激。
【问题讨论】：
标签： database-design
我认为我们需要更多地了解您的设计才能正确回答。例如，我很好奇可能有很多与故障有关的列，很多（不同的）与堵塞有关的列等等。（堵塞不只是一种故障吗？）
你的设计标准化了吗？大概你没有“jam1”、“jam2”等列？！
假设设计良好且规范化，是否拥有一张宽桌子或多张窄桌子的决定是各种因素之间的权衡：
无论采用哪种方式，您都可以使用视图来呈现替代结构，以方便开发人员：
从您的 cmets 中，我现在知道您对机器上 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
);
正如下面有人评论的那样，这些可以让您更轻松地汇总统计信息 - 在统计类型内或跨统计类型。如果需要将新的统计信息添加到统计类型，它也很容易扩展。
【讨论】：
当我在一个表中看到数百列时，我倾向于怀疑数据架构没有被正确规范化。数百列真的是独一无二的，还是它们是可以归一化为更小的表的类似事物的组？
如果您可以减少列数，您就有可能减少所处理的数据总量，从而在多个级别上提高性能。例如，如果您有一条包含 1000 字节数据的记录，并且您想为每条记录更改 1 个字节，则可能会不必要地获取和存储 999 字节。这确实会影响性能。
【讨论】：
规范化可确保您不会在架构中重复数据。
当然，你应该走多远是有限制的。 7 个或更多表的 JOINS 性能不佳。
但是一张怪物桌子？我会分手的。
【讨论】：
您是指 100 种类型的统计数据吗？
一些医学数据库尝试了一种称为“实体属性值”或“EAV”的模式或习语（您可以谷歌搜索这些术语）：原因是关于患者的事实有无数不同类型，可能或可能没有为任何给定的患者捕获，并且 EAV 是一种更好的方式来存储它而不是在一个表中有无数不同的列。
但要注意 EAV 是有争议的：有人说这是“代码味道”和典型的新手错误；其他人说它偶尔（或很少）有用，但取决于（指定和拥有）对元数据的良好支持。
【讨论】：
我倾向于不喜欢列太多的表格。您可能会考虑的一种选择是将统计信息作为行存储在统计信息表中：
CREATE TABLE Statistics (id AS INTEGER PRIMARY KEY, statusType As VarChar,
statusValue As Float);
然后，您只需为要跟踪的每个状态添加一个新行。从数据库的角度来看，这要干净得多，但它确实使获取数据的报告变得更加棘手。
【讨论】：
在这种情况下，我会创建几个表。一个是机器表。一个是问题查找表。最后，两者之间的联结表还包含与状态相关的信息。维护会更容易，写疯狂的报告也会更容易。此外，添加新的状态类型也会更容易。
machine
id
name
description
status_flag
id
caption
machine_history
machine_id
status_flag_id
information
然后您可以执行以下操作： select count(distinct machine_id) from machine_history where status_flag_id = 23 and information
唯一的事情是 machine_history 表中的信息字段可能需要包含数字或字符。如果是这种情况，我会创建两个信息字段，以免影响性能。
另外我假设有一个编程组件可以让您创建一些方法来轻松处理这些数据。
【讨论】：