大列表的数据库设计策略答案

【问题标题】：Database design strategy for large column tables大列表的数据库设计策略
【发布时间】：2013-05-17 03:52:23
【问题描述】：

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

表 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 字段派生如下

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

我的表 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 的方法，因此要求对复杂性变化进行评估有点过分。另外，有什么理由 B 是表而不是视图？
我从您的问题中了解到，表 A 将有大约 650+ 列。如果我是对的，那么 RDBMS 对你来说不是一个好的选择。你应该选择像 cassandra 这样的 NOSQL 数据库。
OP 正在讨论将 away 从 650 列的设计更改为包含 4 列的设计。
@Damien 表 B 已通过 UPDATE SQL 查询进行更新。

【解决方案1】：

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

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

一般应该如何设计这样的表，最佳实践是什么？

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

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

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

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

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

如果您总是每个块有 650 行，则通过规范化不会获得太多收益。如果行数不定（最多 650 行），您将通过仅检索您拥有的内容来获得一点处理。

【讨论】：