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

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站

现在，我想改变这样的方法，即为每个站点和派生字段都有一个字段。我想做下面的桌子。

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 n总是合适的。

很久以前，在关系数据库的古代，在规范化和性能之间有一种权衡。非常优秀的数据库分析人员知道在哪里进行这些权衡。

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

与以前的方法相比，在更新表B派生字段的方法中，SQL会更加复杂吗？

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

如果每个块总是有650行，那么通过规范化不会得到多少好处。如果有可变的行数(最多650行)，则通过检索所拥有的内容，您将在处理过程中获得一些好处。