大列表的数据库设计策略

Question

我正在从事一个项目，我必须处理存储发电站仪表读数的大型列表。目前日期存储在如下表中。

表A

Date, Block No, Station 1, Station 2, ....... , Station N (N can go upto 650)
2013-05-21, 10, 23, -45,........ , 57

现在有另一个表 B，它具有从表 A 派生的字段。

表B

Date, Block No, F1, F2, ....... , FX 
2013-05-21, 10, 23, -45,........ , 57

此处表B字段推导如下

• F1=站1+站3，
• Fx = 站点 p + 站点 r + 站点 w

现在我想改变这种为每个站和派生字段设置一个字段的方法。我想制作如下表格。

我的表A

Date, Block, Station_Name, Reading
2013-05-21, 10, Station 1, 23
2013-05-21, 10, Station 2, -45
.
.
.
2013-05-21, 10, Station N, 57

我的问题是:

• 我提议的规范化设计是否会对处理产生影响？
• 通常应如何设计此类表格，最佳做法是什么？
• 与之前的方法相比，我更新表 B 的派生字段的方法中的 SQL 是否会更复杂？

Answer 1

Will my proposed normalized design have processing impacts?

是的。插入和更新会快一点，而选择会慢一点。然而，规范化的数据库设计是关系数据库引擎旨在处理的。

Generally how should such tables should be designed, what are best practices?

Database normalizatio n 总是合适的，无论您使用关系数据库还是某些 NoSQL 解决方案。

曾几何时，在关系数据库的古代，规范化和性能之间存在权衡。真正优秀的数据库分析师知道在哪里做出这些权衡。

今天，关系数据库引擎能够运行完全规范化的数据库。

Will the SQL be more complex in my approach for updating derived field of Table B compared to earlier one?

会不一样。我不能说它会更复杂。不是每个 block 检索一行，而是每个 block 检索 650 行。

如果每个 block 始终有 650 行，则通过规范化不会获得太多 yield 。如果行数可变，最多 650 行，您将通过仅检索您拥有的行来获得一些处理能力。