大型列表的数据库设计策略

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 = Station 1 + Station 3，
• Fx = Station p + station r + Station w

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

MyTable 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

  

我提出的标准化设计是否会产生处理影响？

是。插入和更新会更快一些，而选择会慢一些。但是，规范化的数据库设计是关系数据库引擎设计用来处理的。

  

一般来说，应该如何设计这样的表格，最佳做法是什么？

无论您使用关系数据库还是某些NoSQL解决方案，

Database normalizatio n始终是合适的。

曾几何时，在关系数据库的古代，在规范化和绩效之间存在权衡。非常好的数据库分析师知道在哪里做出这些权衡。

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

  

在我更新表B的派生字段的方法中，SQL是否会更复杂？

会有所不同。我不能说它会更复杂。不是每个块检索一行，而是每块检索650行。

如果每个块总是有650行，那么通过规范化你不会获得太多收益。如果行数可变，最多650行，那么只需检索您所拥有的内容，即可获得一些处理。